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THE RELIGION OF DATABASE MODEL 

Mark S. Crego 

Abstract 

Somewhere in my past I recall being instructed that there are two taboos that you must never discuss in 
a business environment, politics and religion. However, I note that when database management systems 
are discussed, the topic of model invariably is debated in a manner not unlike a heated religious argument. 
On one hand, you have the "Old Religion", the adherents to the CODASYL Network model, who claim 
performance and integrity as the tenets of their religion. On the other, there are the relational disciples of 
E.F. Codd, who, by their adherence to his 12 commandments, claim flexibility and elegance of data 
structure. 

The purpose of this brief article is to open up the discussion to readers of this DECUS SIG Newsletter, and 
to try to bring some sanity and objectivity to the debate. As the first article in a series, some basic 
evaluation concepts will be proposed. 

The Concept of Application Suitability 

In debating the concept of database model, the notion of whether a particular data model is suitable for an 
application is often lost in the rhetoric. While it is fundamentally true that certain models and hence 
database management systems can implement virtually any data structure, it is not necessarily the case 
that they do so in the "best" manner for any application. 

From a statistical point of view, it has been my observation that less than 5% of data on VAX computers 
is stored in formal databases, even at those sites where database management is fully understood and 
facilitated using a DBMS. Although this is not a bullet-proof justification for non-use of a DBMS, it does 
say that either the database concept is not yet fully accepted by all developers or it is simply not suitable 
for the vast majority of applications. 

For the minority of data that resides in formal databases, it will be found that sites using relational 
products far outnumber those using their network competitors. Does this tell us that the relational model 
is "better"? For some reason I get the feeling that the notion of "better" is really a religious issue and not 
tangible or objective enough to constitute a reasonable criteria. In lieu of this, I suggest that the differing 
models are not "better" or "worse" but rather "more suitable" or "less suitable" for a particular applica¬ 
tion. The key, therefore, is to determine the requirements of the application with no preconceived notion of 
DBMS model, then to evaluate the various alternatives as to their compliance to the requirements. 

The Concept of Performance 

Recently I read an article by Codd which evaluated "Non-Stop SQL", a product which is based in a 
Tandem environment that can achieve, with some very specific hardware configurations, a transaction rate 
of 200 to 300 transactions per second. What was disappointing about the article was that this prophet of 
the relational sect heralded that this "proves" that the relational model has overthrown the "alleged 
performance advantages" of the network model, and in so doing has silenced those who oppose his point of 
view. 

In effect, Codd has placed the notion of performance into the category of topics we file under "religion". 
Although the phrase "performs well" is marginally more objective than "better", it is helpful to define 
what performance implies. For those of us with standard computer configurations, such as VAX’s, and with 
standard disk drives (note that disk technology has had no major "order of magnitude" speed/performance 
breakthroughs in the past 10 years), the concept of performance is may be defined in two essential forms: 
How long does it take to perform a "typical" transaction, and how many "typical" transactions can be 
processed per second. In the latter case, it will be possible to achieve more transactions per second than 
would be possible under the formula l/typical_transaction_time due to facilitating multiple concurrent 
accesses to the database. 

The problem with this definition of performance is defining what the "typical" transaction involves. 
Although there are some fairly standard benchmarks that attempt to qualify the "typical" transaction, it 
really depends completely on the application in question. 
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The Concept of Independence 

The article by Codd which highlighted a specific hardware configuration that would achieve high transac¬ 
tion performance represents a serious problem to those of us that require standard computer 
configurations. The concept of independence in this context implies that the we must evaluate the DBMS 
on its merits alone, without requiring additional hardware in the form of a specialized CPU or database 
machine. 


The Concept of Integrity 

That the majority of information on VAX’s lies in RMS files and not databases is a strong argument that 
transaction-level integrity is not recognized as a significant factor for most applications, for it is integrity 
that is the most distinguishing factor of a DBMS. In general terms, there is great similarity between the 
features of integrity offered in the various models, such as maintaining a journal of transactions, ensuring 
that a transaction is completed before making a permanent change to the data. 

Nevertheless, there are notions of integrity that are relevant to the model chosen. These issues have to do 
with how, when a record (or relation) is added, updated, or deleted, that all other relevant records or 
relations in the database are added, updated, or deleted. Since the network model implements explicit links 
to the related records and the relational does not, there are clear implications to how you "tie-in" those 
related records or relations. Note, however, that the manner in which records or relations are related or 
joined to each other is highly application specific. 

The Concept of Flexibility 

For anyone who has had to change a network schema, and unload/reload a network database, the concept 
of inflexibility takes on new meaning. As a result, this apparent weakness in the network model in 
flexibility has become a major point of argument in the model debate. 

In this case, the volatility of the application, its tendency to change is a most relevant factor. Although the 
relational model is designed around the possibility of change and accommodates changes well, it does so at 
the expense of speed of access and update. Whether this is relevant depends largely upon schema design 
and application requirements. 

The Concept of Tools 

Many decisions to purchase a DBMS lie not in the merits of the model but rather in the capabilities for 
application development and ad-hoc query/reporting that the product offers. This then becomes analogous 
to adhering to a religion for some obscure tenet that seems pleasing to you, rather than looking at the 
whole body of doctrine. 

It is generally the case that the relational products in the VAX environment offer a wider variety of tools. 
For example, when DEC announced its COBOL Code Generator, the DBMS with which it interfaced was 
Rdb/VMS and not VAX DBMS (Rdb is relational and VAX DBMS is CODASYL-compliant network). 
Oracle, Ingres, and now Rdb all embody SQL, a standard for query languages. Oracle and Ingres have both 
implemented forms of distributed DBMS. It should be noted that these capabilities are not so inherent to 
the model as they are to the funding and marketing efforts of their respective vendors. 

Still, in order to make a rational decision for a DBMS, the concept of tools is relevant, but only in light of 
the requirements of the application. The objective should be to determine what tools are essential, then to 
find those tools — they need not in every case be integrated with the DBMS. 

Summary 

This brief treatise has attempted to isolate some concepts that can render objectivity to the religion of 
database models. In every case, the argument must be focused upon the requirements and characteristics 
of the application under evaluation and not upon model-specific dogma. 


DMS-2 



The Wombat attb 4($21 

EXAMINER itapatflf 

‘‘Increases the Circulation of Anyone in America” Volume 8 Number 12 
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Datatrieve or any 4GL product. Submissions on magnetic media are preferred but almost any type will be 
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Warner Lambert Company 
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Chairman’s Corner 

Joseph Gallagher, 4GL Solutions, Kansas City, MO 


Those of you who were not in Nashville missed one the best and most successful symposium that DECUS 
has had. The facilities at Opryland were outstanding: southern hospitality made everyone feel delighted to 
attend. A larger than anticipated attendance assured financial success for the 1987 DECUS budget. 

There was much more diverse material presented at sessions sponsored by the DTR/4GL SIG at this 
symposium than in the past. The expansion of our activities into the Digital and non-Digital 4GL areas are 
becoming more evident. 

There have been many changes in the DTR/4GL Steering Committee. Mary Ann Fitzhugh is our new 
Counterpart for DATATRIEVE and the Digital 4GL Products. Mary Ann is the former counterpart to the 
OA SIG. We are looking forward to productive interactions with her. 

The Powerhouse Working Group had several successful presentations and meetings at the Nashville 
Symposium. Randall Barth, the Powerhouse Working Group Chair chosen at the San Francisco, now works 
for DEC; Fred Vietri of TSO Financial Corp. has agreed to serve as Powerhouse Working Group Chair. 

At a Smartstar Birds-of-a-Feather sessions at Nashville, a Smartstar Working Group was formed. Leslie 
Byars of Corning Electronics has agreed to serve as Working Group Chair. 

The Accent-R User's Group met during the Nashville Symposium. That group has its own organization 
independent of DECUS. However, Winston Tellis of Fairfield University, the Chair of the Accent-R User's 
Group, has agreed to act as liaison with the DTR/4GL SIG. 

Pat Scopelliti of Corning Glass Works and Lorey B. Kimmel of Thomson-CGR Medical Corporation are 
now Associate Newsletter Editors. We look forwarding to seeing their contributions to the Wombat 
Examiner and 4GL Dispatch. 

Enjoy the hot summer, but try to stay cool. 
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Wombat Wizard 

Philip A. Naecker, Consulting Software Engineer, Altadena, California 


Greetings oh Great Wizard: 

I have what is a relatively simple problem to solve in FORTRAN, but appears to be quite difficult in 
DATATRIEVE. I want to select records, from an indexed file, which satisfy exactly five of a possible six 
selection criteria. Then I want to use the report writer to print out specific information contained in the 
selected records. 

For example, assume the record definition looks like: 


CRITERIA. 


05 

CRITERIA A 

PIC X. 

05 

CRITERIA B 

PIC X. 

05 

CRITERIA C 

PIC X. 

05 

CRITERIA D 

PIC X. 

05 

CRITERIA E 

PIC X. 

05 

CRITERIA F 

PIC X. 


Assume the fields contain either an ASCII blank or some character. If I want the selected records which 
contain exactly five non-blank conditions, there are five valid combinations: 

ABCDE 
ABCD F 
ABC EF 
AB DEF 
A CDEF 
BCDEF 


This combination can be searched for with a rather specific Record Selection Expression. 

But this is a specific example of a rather general condition. It becomes much more complicated if each field 
contains several valid criteria ("W'Y'Z". and "X") and several invalid criteria ("GV'D", and "Q") which 
can be mixed and matched to produce the ultimate valid combination. 

Any suggestions on how to solve this problem? Thanks a bunch for your help. 

Thomas F. Glowacki 

Dear Tom: - You don’t want much, do you? Just a general solution, huh? Well, let’s see what we can do. 

First, I’m a little unclear on your exact needs. I assume your reference to an indexed file is because 
CRITERIA (the 03 level in the record definition above) is a key in the file. Of course, if other fields are 
keys it doesn’t matter to DTR that the file is indexed. However, since you may not have indexed the file 
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on CRITERIA, let’s first talk about some solutions to that simpler case (with the file sequential on 
CRITERIA!. 

One thing I would suggest would be a few computed-by variables and some simple arithmetic operations to 
simplify the logic of the situation. Consider the following: 

DECLARE CRITERIA_A_VALUE COMPUTED BY 
CHOICE 

CRITERIA_A EQ "W","Z","X" THEN 1 
ELSE 0 
END_CHOICE. 

(do the same thing for CRITERIA_B through CRITERIA_F) 

DECLARE CRITERIA_SUM COMPUTED BY 

(CRITERIA_A_VALUE + CRITERIA_B_VALUE + CRITERIA_C_VALUE + 

CRITERIA_D_VALUE + CRITERIA_E_VALUE + CRITERIA_F_VALUE) 

Then you could do an RSE with a selection criterion like: 

...WITH CRITERIA SUM EQ 5 

That would make your code much more maintainable and readable. Of course, you could also play games 
with the COMPUTED BY clauses to make some values "more valid" than others, or to make some "less 
valid". For example, you might make CRITERIA_B work like this: 

DECLARE CRITERIA_B_VALUE COMPUTED BY 
CHOICE 

CRITERIA_B EQ "W'V'Z'V'X" THEN 1 

CRITERIA_B EQ "Q" THEN -5 ! To eliminate any with Q 

ELSE 0 
END_CHOICE. 

By the way. if you are trying to find out if AT LEAST ONE criterion contains a particular value, you have 
two simple ways (as well as one hard way using the explicit tests on every field). The first simple way is a 
little trick the Wiz picked up at the last Wombat Magic at DECUS. (This one was a winner by the way!) 

...WITH " * EQ CRITERIA A. CRITERIA B. CRITERIA_C. ... 

Note that the usual order for the Boolean has been reversed, with the constant value on the left (in this 
case, the quoted space) and the variables from the record on the right (CRITERIA_A. etc.). The advantage 
here is that you have a single Boolean expression that will evaluate to true if ANY of the CRITERIA_x 
equal to " ". This is much simpler (and possibly clearer) than: 

...WITH CRITERIA_A EQ " " OR 
CRITERIA B EQ " " OR 


Another way to handle this will make SIG Chair Joe Gallagher happy - use an Inner List. Consider this 
revised record definition: 

03 CRITERIA. 

05 CRITERIA_A PIC X. 

03 CRITERIA_STRUCTURE REDEFINES CRITERIA. 

04 CRITERIA_LIST OCCURS 5 TIMES. 

05 CRITERION PIC X. 
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This structure would allow the RSE’s of the form: 

...WITH ANY CRITERIA LIST WITH CRITERION EQ " " 


You could also accomplish the counting function you desired with an RSE like the one in the following 
REPORT statement. 


REPORT my_domain WITH 

(COUNT OF CRITERIA_LIST WITH CRITERION EQ " ") EQ 5 
report statements go here 
END_REPORT 

Alas. I suspect that none of these solutions is adequate for your needs because you apparently want to use 
the CRITERIA field as a key. If you were to do this in a 3GL like FORTRAN or COBOL, you would create 
a series of match keys (each of your ABCDEF combinations) and do a READ using that each of those key 
values in turn. This would involve an outer loop in your program, each pass through the loop changing a 
different byte in the match key. Note, however, that even in a 3GL you would have to construct a key for 
each valid case, since you cannot use RMS key lookups on just certain bytes in the field (that is. you can't 
do a partial key lookup except in the trivial case where the part of the key of interest is the first (leftmost) 
part of the key). Also, you can’t do complex index selections in RMS files, although some database systems 
have some capability to select records based upon only their index values (such as Rdb/VMS) or by doing 
a bit-mapped index operation (such as Interbase from Interbase Software Corporation). 

I suggest that you do the same thing in Datatrieve that you would in a 3GL: construct the keys that make 
up the "valid" cases then instruct RMS to look up the records for each of these cases in turn. In 
Datatrieve. the easiest way to do this is to construct a domain with all of the valid values. You can populate 
or modify this domain on the fly if you like. Then use a FOR loop on this domain and a FOR (or REPORT) 
loop on your original domain to locate the records of interest. For example: 

DEFINE DOMAIN INTERESTING_KEYS USING INTERESTINGJCEY ON INTERESTING_KEYS.DAT; 

DEFINE RECORD INTERESTING_KEY USING 
01 DATA. 

03 CRITERIA. 

05 CRITERIA_A PIC X. 

05 CRITERIA_B PIC X. 

05 CRITERIA_C PIC X. 

05 CRITERIA_D PIC X. 

05 CRITERIA_E PIC X. 

05 CRITERIA_F PIC X. 

03 0THER_STUFF. 

05 GROUP USAGE WORD. 

05 CATEGORY USAGE WORD. 

J 

DEFINE FILE FOR INTERESTING_KEYS KEY=CRITERIA(UP); 

DEFINE TABLE CRITERIA_GR0UP USING INTERESTINGJCEYS 
CRITERIA : GROUP 
ELSE 0 
END_TABLE; 

The procedure with your report might then look like this: 
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FOR I IN INTERESTING JCEYS BEGIN 

REPORT M IN my_domain WITH CRITERIA EQ I.CRITERIA 
report statements go here 
ENDUREPORT 

END 

This approach will produce a different report file for each report; that is. one report for each key value. If 
you want to have all of these reports concatenated together, you could then use an FN$DCL statement to 
APPEND the reports into a single file. The report file will be emptv for those records in 
INTERESTING_KEYS that have no match. 

You can get a single report file using a CROSS instead of the FOR loop and the implied FOR in the 
REPORT statement: 

REPORT I IN INTERESTINGJCEYS CROSS M IN my_domain OVER CRITERIA 
report statements go here 
END__REPORT 

You can also limit the CROSS to certain records in INTERESTING_KEYS, using the GROUP and 
CATEGORY fields. For example: 

REPORT I IN INTERESTING_KEYS CROSS M IN my_domain OVER CRITERIA WITH 
I.GROUP EQ 5 OR I.CATEGORY EQ 39 
report statements go here 
END_REPORT 

Note that the order of the two domains in the cross is important - if you want to use the index in 
my_domain it must follow INTERESTING_KEYS. You can also use the virtual variables I defined before 
to select the records of interest from INTERESTING_KEYS: 

REPORT I IN INTERESTING JCEYS CROSS M IN my_domain OVER CRITERIA WITH 
I.CRITERIA_SUM EQ 5 

report statements go here 
END__REPORT 

Note that CRITERIA_SUM is qualified to point to the INTERESTING_KEYS domain, although it doesn't 
really matter in this particular case. 

If you don’t need to use the index in your domain but you like the flexibility provided by the 
INTERESTINGKEYS domain, then you might want to use the following approach: 

! To get all the records belonging to criteria-group 3 
REPORT my_domain WITH CRITERIA VIA CRITERIA_GROUP EQ 3 
report statements 
ENDJREPORT 

If, for some reason, you can't use the CROSS or nested-FOR loop approaches I’ve outlined here, then you 
really only have one more solution using Datatrieve: Callable DTR. Using Callable, I can think of another 
five or six ways to approach the problem. However, my favorite is also the most flexible and probably the 
least used: in fact, I don’t know of anyone besides myself who has applied this technique. Callable DTR has 
a little-known feature which allows the callable program to start up to five different Datatrieve sessions 
simultaneously. Each session gets it’s own DAB (Datatrieve Access Block), so it really is five separate DTR 
sessions under the control of a single program. In this case, we will only need two sessions: one for record 
selection and one for reporting. 
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The basic model is as follows. Start up two DTR streams by making two calls to DTR$INIT with different 
DAB addresses. In the first stream, start a REPORT statement running with it’s input coming from a 
PORT (a port is a communication device between the program and DTR). Once you have the REPORT 
statement running, it will keep asking (stalling) for records until you send it a PORT_EOF (end of file). In 
the second stream, start up as many FOR loops as you need to select the records of interest. The records 
can come from different sources, have different RSE’s on the same source, be in different orders, or in 
general have any characteristics you want. Take the records from these diverse record streams and shove 
them BACK INTO Datatrieve, into the first record stream - the one that is asking for input! Once you have 
given it all the data you want to report on, send the port an EOF, and Voila! - a report will be created! The 
report can have any sort order you desire, the report statement can apply different selection criteria, and 
in general there are no limitations on the REPORT statement itself. 

Actually, it's just about as simple to write as it is to explain. If you have a report that is to be created from 
a complicated series of record streams, then this is just the ticket for you. 

Good luck! 

The Wombat Wizard 


Wombat Magic - Spring DECUS U.S. Symposium, Nashville, TN 

Edited by: Steven Cordiviola, Kentucky Geological Survey, Lexington, KY 


This article is the presentations from the WOMBAT MAGIC session held during the 1987 Spring DECUS 
Symposium. The pieces of magic were transcribed from the presenter’s transparencies and from a 
transcription of the audio tape. Unfortunately, we were not able to salvage all the material, nor was it 
possible to catch the "atmosphere" of the session. There is always something special about Wombat Magic 
and this session was no exception. 

The editor apologizes to any authors who’s names are misspelled or affiliations are wrong or missing. My 
thanks to MS. Shirley Dawson, who keyboarded the transparencies. 

Douglas Cropper, DATATRIEVE Developer, Digital Equipment Corporation 

Doug wanted a quick way to compute car payments... 

DEFINE PROCEDURE MORTGAGE 
DECLARE APR USAGE REAL 

EDIT_STRING IS Z(2)9V99. 

DECLARE BALANCE USAGE REAL 

EDIT_STRING IS Z(9)9V99. 

DECLARE TERM USAGE INTEGER 
EDIT_STRING IS Z9. 

DECLARE PERIODS COMPUTED BY TERM * 12. 

DECLARE IPP COMPUTED BY APR/1200. 

DECLARE POWER USAGE REAL. 

DECLARE MONTHLY COMPUTED BY 

((IPP*BALANCE)/(1- (1/POWER))). 

DECLARE TOTALPI COMPUTED BY MONTHLY * PERIODS. 

DECLARE TOTALI COMPUTED BY TOTALPI - BALANCE. 

APR = 13.5; 

BALANCE = 50000; 
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TERM = 30; 


APR = *."annual percentage rate <13.5>" 

WHILE APR NE 0 
BEGIN 

BALANCE = *."the mortgage amount <50000>" 

TERM = *."the length of the loan <30>" 

POWER = IPP+1 

REPEAT PERIODS - 1 ! EDITORS NOTE: The 

BEGIN ! FN$P0WER function 

POWER = POWER * (IPP+1) ! can replace this 

END ! portion of code. 

PRINT SKIP 4,"Term is ", FORMAT (TERM) USING Z9,"years" 
PRINT "Annual percentage rate is ", FORMAT(APR) 

USING Z9V99 , 

PRINT "Monthly payment is " ,FORMAT (MONTHLY) USING 

$(5)V99 

PRINT "PRINCIPAL IS ",FORMAT (BALANCE) USING 

$(9)V99 

PRINT "Total interest is ", FORMAT (TOTALI) USING 

$(9)V99 

APR = 13.5; 

APR = *."annual % rate, use 0 to exit <13.5>" 

BALANCE = 50000; 

TERM = 30; 

END 

END-PROCEDURE 


DTR> :MORTGAGE 

Enter annual percentage rate <13.5>: 9.5 
Enter the mortgage amount <50000>: 75000 
Enter the length of the loan <30>: 30 


Term is 30 years 

Annual percentage rate is 9.50 % 

Monthly payment is $630.64 
Principal is $75000.00 
Total interest is $152030.54 

Enter annual percentage rate, use 0 to exit <13.5>: 9.0 
Enter the mortgage amount <50000>: 13000 

Enter the length of the loan <30>: 5 


Term is 5 years 

Annual percentage rate is 9.00 % 

Monthly payment is $269.86 
Principal is $13000.00 
Total interest is $3191.42 

Enter annual percentage rate, use 0 to exit <13.5>: 0 
DTR> DTR-8 




Herb Reines, Reznick, Fedder & Silverman, Bethesda, Md. 

w/Help from: Joe Gallagher, Doug Cropper, and Tom Considine 

Problem: 

Some users need to be restricted from editing CDD definitions in DTR. 

Solution (one of many I'm sure): 

$ define DTR$EDIT "There" 

(Placed in the login file or even at the syslogin level) 

Then: 

$ DTR32 

DTR> edit yachts 

There is not a valid editor within VAX DATATRIEVE 


Fred Van Itallia, DuPont 


Test for Success 

Fred had a problem in batch jobs to convert dates, which were stored as text strings, to DATATRIEVE 
DATES. For example, a text file contains a date in the form "13-1-87" and a user wishes to enter that data 
into a domain via a BATCH job, DATATRIEVE will choke. The user has no w’av to tell if the 
DATATRIEVE procedure died before processing all the records. The batch job will just continue with the 
next command. Fred’s solution is to put a PRINT "SUCCESS" on filespec statement in the 
DATATRIEVE procedure which will execute only if no errors are encountered. Then he uses DCL com¬ 
mands to see if the file contains "SUCCESS" before executing the rest of the batch job.... 

In the BATCH command file... 

$ ON ERROR THEN GOTO ERR0R_MSG 

$ DTR 

:procedure_name 
$! MORE COMPLEX PROCESSING 

$ IF F$SEARCH("TMP.LIS") .EQS. "" THEN GOTO ERROR_MSG 
$ EXIT 
$ ERR0R_MSG: 

$! WHAT EVER YOU WANT THE PROCEDURE TO DO... 

$ EXIT 

In the DATATRIEVE procedure the code might look like this.. 

READY DATE_CONV_DOM MODIFY 
FOR DATE_C0NV_D0M 

MODIFY USING DATE = FN$DATE(DATE_TXT) 

PRINT "SUCCESS" ON TMP.LIS 
EXIT 


If an error occurs during the FOR statement. DATATRIEVE will exit the procedure before it executes the 
PRINT statement. Thus the word "SUCCESS" will not be written to the file TMP.LIS. 
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Bart Z. Lederman, ITT World Communications 

How can you get the average of 2 dates, for example to find the midpoint of a project... 

PRINT ("12-APR-1987" & "14-APR-1987")/2 

...this DOES NOT WORK because you can't divide dates. If you create a record definition (or computed by 
fields) similar to these: 

RECORD DATE_REC. 

01 DATE_RECORD. 

10 DATES. 

20 BDATE USAGE DATE. 

20 EDATE USAGE DATE. 

10 QUADS REDEFINES DATES. 

20 BQUAD USAGE QUAD. 

20 EQUAD USAGE QUAD. 

10 MDATE COMPUTED BY 
(BQUAD & EQUAD)/2 

EDIT_STRING DD-MMM-YYYY. 

10 MTIME COMPUTED BY 
FN$TIME(MDATE) 


Now you can use these filed to print the correct dates... 


DTR> 

BDATE 

12-APR-1987 

12-APR-1987 


PRINT BDATE,EDATE,MDATE,MTIME OF rse.. 
EDATE MDATE 

14- APR-1987 13-APR-1987 

15- APR-1987 13-APR-1987 


Tom Fournier 


MTIME 

00 : 00 : 00.00 

12 : 00 : 00 . 


"Waltzing Matilda" 


Tom wanted a quick and dirty way to find out the number of characters in a string (apparently his system 
manager did not link in the function FN$STR_LEN available on the DTR/4GL SIG tape- ed.). The magic 
involves concatenating unique characters to the string of interest then using the DATATRIEVE supplied 
function FN$STR_LOC. Tom uses 2 tildes as a unique string.... 

DECLARE IN_STRING PIC x (80). 

DECLARE SIZE PIC 99. 


SIZE = FN$STR_L0C(IN_STRING| | | 

A second piece of magic shows that there is more than one way to approach a problem. In this case. Tom 
wanted to exclude fields in a record which were equal to 0... 

DEFINE RECORD STUFF_REC USING 
01 REC. 

05 NUMBER-1 PIC 99. 
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05 NUMBER-2 
05 NUMBER-3 
05 ... 


PIC 99. 
PIC 99. 


the most common solution would be an RSE similar to: 

FOR ALL STUFF WITH NUMBER-1 = 0 OR 

NUMBER-2 = 0 OR NUMBER-3 = 0 BEGIN 
etc... 


Tom’s solution, thus magic is to reverse the order: 

FOR ALL STUFF WITH 0 = NUMBER 1, NUMBER 2, NUMBER_3 BEGIN... 


Lorey Kimmel 

(Editors note: Lorey presented her magic at DECUS. but was kind enough to send me the text which 
explains very clearly what she presented.) 

Following is a simple Menu procedure you can use to present menus to users. By using Tables as the basis 
for the menu, it is very easy to add/delete/modify what is presented on the menu. 

I have also included a "sample" table, and a command procedure that can be used to execute the 
Datatrieve Procedure MENU from DCL, as well as print any type DTR files created by the user while in 
Datatrieve. If you consistently create all output report files with a type of .DTR, this procedure will print 
them once the user exits Datatrieve. 

Each section will be explained. 

MENU is the Datatrieve Procedure used to display a menu and execute a Datatrieve Procedure based on 
what the user enters. 


PROCEDURE MENU 

SET DICTIONARY menu_dictionary 

DECLARE CH PIC 9(2). 

DECLARE STOP PIC 99. 

DECLARE STOP COMPUTED BY 
"TT" VIA USER_TABLE. 

DECLARE SEL PIC XX. 

CH = 001 


!for ease in "controlling” the 
environment, I have placed all 
"completed" procedures in one 
dictionary 

!CH is used to calculate which 
item from the table to be 
displayed 

[STOP is computed to determine 
when to STOP the WHILE statement 
which determines how many items 
will be displayed 


ITT is defined in the table, (See 
below) 

!SEL is used to input the user's 
SELection from the menu items 
displayed 

!CH starts at 1, the first entry 
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of the table 


FN$WIDTH(80) !Make sure screen is clear, and 

set to 80 characters for display 
of the menu 


PRINT "Datatrieve Menu",SKIP 

!The following BEGIN-END loop actually displays the menu. By using the 
!FN$INIT combined with FN$STR_EXTRACT functions, you are assured the 
!right table are displayed in the proper format. By incrementing CH by 
!1 (CH = CH + 1) succeeding entries are displayed 

WHILE CH LE FN$NINT(ST0P) 

BEGIN 

CHOICE 

CH < 10 THEN 

PRINT FN$NINT(FN$STR_EXTRACT(CH, 1 , 2 ))(-), 

SPACE 1, FN$STR_EXTRACT("0"|CH, 1,2) VIA 
USER_TABLE 
CH > 9 THEN 

PRINT FN$NINT(FN$STR_EXTRACT(CH, 1 , 2 ))(-), 

SPACE 1, FN$STR_EXTRACT(CH,1,2) VIA 
USER_TABLE 

ELSE PRINT "Invalid Choice" 

END_CH0ICE 
CH = CH + 1 

END 


PRINT SKIP, " 99 Exit Menu" 


SEL = *.'Selection' 

IF SEL = "99" THEN ABORT 


[Input user's SELection 
!"99" means Exit Menu 


! The following statement creates the Datatrieve logical EXECUTE_PROC by 
! looking at the second table entry. By stringing "A" with the value of 
! SEL, we use the Procedure name associated with a menu item displayed ! 


(see explanation of table below). 

FN$CREATE_L0G("EXECUTE_PROC",FN$STR 
USER_TABLE) 

:EXECUTE_PR0C 

FN$DELETE_L0G("EXECUTE_PR0C") 

:MENU 

RELEASE ALL 
FN$WIDTH(80) 

END PROCEDURE 


EXTRACT("A"|SEL,0,3) VIA 

!This statement executes (:) the 
logical name created above 

!You must DELETE the logical name 
assignment 

[After the desired procedure is 
executed, re-execute MENU 
[Release all variables 

[clear screen 
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A sample table and the appropriate entries are listed and explained below. 

TABLE MENU1_TABLE 
01 : "Procedure Description" 

A1 : "DTR_PROCEDURE_NAME" 

TT • ?f l ,f 


ELSE "Invalid Table Entry" 

END_TABLE 

Notice how entry 01 has a corresponding "Al" entry, entry 02 would have to have a corresponding "A2" 
entry, and so forth. This allows one entry to contain the information to be displayed on the screen (the 
numerical entry), and one entry to contain the actual procedure to be executed (the "A" entry). If I had an 
02 and corresponding "A2" entry, then "TT" would have to be incremented to "2". "TT" must contain the 
total number of procedures listed in the table, not the total number of table entries. You MUST assign a 
value in DCL 


IThis is the text actually 
displayed on the screen 
IThis is the actual Datatrieve 
procedure name 

IThis entry (Table Total) MUST 
contain the total number of 
procedures used in the table 


$assign datatrieve_table USER_TABLE BEFORE 

executing the Datatrieve procedure MENU. By adding in this functionality, you can create different tables 
for different user’s and/or applications. Below I have included a sample DCL procedure used to execute the 
Datatrieve Menu procedure. 

$!! THIS SECTION CLEARS THE SCREEN 

$! ! 

$ devt = f$getdvi("tt","devtype") 

$ if devt .ne. 96 then goto N0NVT100 
$ write sys$output "" 

$ write sys$output "" 

$ goto EXIT_CLEAR 
$NONVT100: 

$ write sys$output "" 

$ write sys$output "" 

$EXIT_CLEAR: 

$!! 

$IThis section checks for a node name, as we have Datatrieve 
$ I installed on only one node of our cluster 
$! 

$ node==f$getsyi("nodename") 

$if node .ne. "node name with Datatrieve" then goto - 
dtr_no_access 

$ I the next statement keeps all output files in the user's home 

$! directory 

$SET DEFAULT SYS$L0GIN 

$dtr32=="$sys$system:dtr32tdms.exe" 

$assign/user sys$command sys$input 

$! 

$! the next statement executes the Datatrieve procedure MENU 
$dtr32 execute menu_dictionary.menu 
$ I 

$! after exiting from Datatrieve, search for any type DTR files 
$! and if they exist, print them to specified print queue 
$if "''f$search("*.dtr")'" .eqs. "" then exit 
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$inquire/nopun/local ans "Please enter print que [SYS$PRINT] > " 
$if ans .eqs. then ans = "SYS$PRINT" 

$print/delete/notify/que='ans' *.dtr;* 

$goto exit 

$! 

$! this section is for node without access to datatrieve 
$!dtr_no_access: 

$write sys$output "" 

$write sys$output "" 

$write sys$output "You cannot access Datatrieve from this node"" 
$write sys$output " Press enter to continue" 

$write inquire/nopun dummy "" 

$exit: 

$exi t 


The only problem I have encountered with this procedure is that when using the Report Writer function of 
Datatrieve, Datatrieve opens the output file regardless of whether or not anv actual records are to be 
printed. A type .DTR file will be created, but it will be empty, and this procedure will attempt to print the 
empty file, which will of course not print. This has been a little frustrating to my user’s as they run a 
report, and then rush to the printer to get their report, and nothing is there. Any suggestions as to a 
solution to this problem would be welcome. 

Bill Tabor, W.l. Tabor, Inc., Coral Springs, Florida 

Bill’s magic involves some PRO-DATATRIEVE hints and kinks... 

PRO DATATRIEVE does not provide a dictionary compress utility, so this will clean-up your dictionary 
after it becomes cluttered from editing sessions. Users must EXIT from DATATRIEVE after the DEFINE 
statement so as to trick the software into using the new dictionary. 


INVOKE DTR 

DTR> EXTRACT ALL ON X 

DTR> DEFINE DICTIONARY DTR$DIC 

DTR> EXIT 


INVOKE DTR a second time and execute X 
DTR> @X 


Now use the PRO’s purge utility to clean up the dictionary. 

Another useful tidbit involves VMS SORT, which has the capability to extract partial records. When 
writing a DATATRIEVE report on a subset of a large datafile, it will be much more efficient to define a 
domain accessing a sequential file of the sorted records. Invoke SORT to extract the records from the main 
datafile and to write the sorted output to the sequential file. Then use DATATRIEVE against that new file. 
You may get a 6 or 7 times increase in performance. 

Steve Convey, Consultant 

While trying to impress a client. I began playing with the FAMILIES database... 

DEFINE TABLE WIFE_TABLE OF FAMILIES USING 
FATHER : MOTHER 
ELSE "** SINGLE **" 

END TABLE 
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DEFINE TABLE HUSBAND_TABLE - 

DECLARE WIFE COMPUTED BY NAME VIA WIFEJTABLE. 

DECLARE HUSBAND _ 

DECLARE SPOUSE COMPUTED BY 

IF SEX = "M" THEN NAME VIA WIFEJTABLE 
ELSE NAME VIA HUSBANDJTABLE. 

DECLARE NAME COMPUTED BY KID_NAME. 

DECLARE SEX COMPUTED BY 

IF FN$STR_EXTRACT(1,1,NAME) = "A", "E","I","O","U" THEN "F" 
ELSE "M". 

FOR FAMILIES PRINT PARENTS, ALL KID_NAME, SPOUSE OF KIDS 

A blast from the past...courtesy of Bill Opalka (DTR-11 developer)... 

Presented by Bert Roseberry 


What does this do? 

(in an old version of DATATRIEVE-11 

RW> AT TOP OF PAGE PRINT NEV-PAGE 

answer: EMPTIES A BOX OF PAPER IN LESS THAN 10 SECONDS! 

Pat Scopelliti, Corning Glass Works 

"Plotting what ain’t really there" 

Magic from Richard Copeland (in absentia) 

A file contains a series of data points. It is desired to make a plot of these points versus their "point 
number" on an x-y plot, e.g.: plot point number l’s value on the Y axis versus the number 1 on the X axis, 
plot point number 2"s value on the Y axis versus the number 2. etc. How can you do this plot without 
having the x value physically residing in the data file? 

Here’s a solution... 

DTR> declare x_value computed by running count. 

DTR> plot x-y all x_value, point 

Joe Gallagher makes a comment: This will screw-up the end point. An old magic session Joe edited showed 
how to get around this problem by multiplying the RUNNING COUNT by 99.99. The graph will not be 
effected and the end point will come out at exactly the right point. Phil Dickerson was the first to point 
this out, but now the DATATRIEVE command SET LIMITS to override the scaling. 

John Henning, DEC 

PROBLEM: Do not allow users to leave DATATRIEVE (e.g. for security) 

ANSWER: $ SET PROMPT = "DTR> " 

Gary Burton, DuPONT 

Gary tried to use a laser printer from DATATRIEVE. He wanted to send escape sequences for various 
fonts, landscape orientation, etc. Using the REPORT WRITER, Gary sent the sequences via the appro¬ 
priate DATATRIEVE procedure.. 

DTR> REPORT DOMAIN ON NODE::LASER 
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RW> AT TOP OF REPORT :PRINT_STATEMENT, NEW_PAGE 
RW> PRINT domain 
RW> END_REPORT 

This technique can also be used to print more information than is normally allowed at top of reports. 

Bob Hoover, HLP, Prescott, AZ 

While trying to populate a data file with unique keys can be difficult especially when you are just trying to 
test the application.. One way to create unique key fields is to use RUNNING COUNT... 


DTR> FOR domain STORE USING 
BEGIN 

LNAME=LNAME||RUNNING COUNT 
END 

Joanne Martin, Anheiser-Bush 

FIELD LEVEL ACCESS CONTROL 

In trying to develop an application. Joanne wanted to create a way to control what fields various users 
could have access too... 

First some rules: 

1. All users may see all data 

2. Accounts share data file but use separate dictionaries and separate logins. 

3. A MALICIOUS USER CAN BREAK ANYTHING! 

The following DOMAINS use different RECORD DEFINITIONS on same file. 

DTR> define domain USER1 using USER1_REC on FILE.DAT 
DTR> define domain USER2 using USER2_REC on FILE.DAT 

define record USER1 using define record USERS2 using 
01 USER1 REC. 01 USER2 REC. 


03 

INDEX 

03 

INDEX 

03 

USER 1 FIELD 

03 

FILLER 

03 

FILLER 

03 

USER 2 FIELD 


Phil Naecker, Wombat Wizard 

Phil thought about a number of ways to keep users from using an editor in DATATRIEVE. One way is to 
build DATATRIEVE without links to any editors.. 

$ TYPE DTR$LIBRARY:DTRBUILD.COM 

$. 

$! 

$ LINK .../LIBRARY , SYS$INPUT:/OPTION <== Find this line 
stuff. . . 

/INCLUDE = (EDT, TPU, . . .) <== Make a change here 

CHANGE TO 

/INCLUDE = ( ... ) 
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Another way is to use the DMU utility, provided you have the privilege, and BANISH users from Updating 
the dictionary... 

$DMU ==$DMU 
$DMU 

DMU> SET PROT CDD$TOP/BANISH=U 

Bryan Dooley GE - Major Appliances Appliance Park, Louisville, KY 

(Editors note: Bryan also presented this magic at the symposium, but sent a complete text file for inclusion 
in the Wombat Examiner...thanks Bryan!} 

Because several of our users were used to using systems in which the field terminator was a carriage 
return, the default behavior of FMS screens in DTR32 in which the TAB key is the field terminator, and 
the RETURN key is a screen terminator was causing a good deal of confusion. The results were failures of 
various edit checks, and sometimes incomplete records were being entered in the files involved. In order to 
make our DTR32 applications more like existing applications, we created a user defined function to swap 
the TAB and RETURN key functionality in FMS under DTR32. Listed below is the FORTRAN routine we 
inserted in DTRFUN.OLB and the addition to DTRFND.MAR made to define the function to DTR32. 

INTEGER FUNCTION SWAP_FMS_KEYS*4 

Q'k'k 'k'k'k'kit^&'k'k'k'k'k 'kjc&'k'k&ic'k'k'k 'k'k'k'k'k'k^&'k'k^'k'k&'k'k'k'k&Tk'k'k-k'k'k'k'k'k'k'k'k'k'k-k-k-k Q 

C SWAP_FMS_KEYS - THIS ROUTINE SWAPS THE FUNCTION OF THE RETURN 

C AND TAB KEYS IN FMS FOR DATATRIEVE 

C 

C AUTHOR: BRYAN DOOLEY 

C DATE : 12/16/85 

C 

Q'k'k'k 'k'k'k'k'k'k'k^i: 'k'k^'k'k'k'k^-^ic'k^'k'k'k^'k'k'k'k'k'k^'k'k'k'k'k'k'k'k-k 'k'k-k'k 

IMPLICIT INTEGERS (A-Z) 

INTEGERS KEYTABLE(4) ! KEYS TO BE SWAPPED 

DATA KEYTABLE/13,1033,11,1037/ 

SWAP_FMS_KEYS = FDV$DFKBD(%DESCR(KEYTABLE),2) 

RETURN 

END 


;FN$FMS_SWAP - Alter function of RETURN and TAB on FMS keyboard 

; output is a longword status return 

I 

$DTR$FUN_DEF FN$FMS_SWAP, SWAP_FMS_KEYS, 0 
$DTR$FUN_0UT_ARG TYPE = FUN$K_STATUS 
$DTR$FUN_NOVALUE 
$DTR$FUN_NOOPTIMIZE 
$DTR$FUN_END_DEF 


It should be noted that the FDV$DFKBD function in the FORTRAN routine can be used to re-map the 
FMS keyboard in any way desired. The documentation for this routine is in the FMS Form Driver 
Reference Manual. 

The only restriction for use of this function is that a DTR statement that uses FMS must be executed 
before FN$FMS_SWAP is executed. This is because the initial READY of a domain with an FMS form 
defined, or the initial DISPLAY_FORM statement, causes certain FMS workspaces to be created and 
initialized. These workspaces must be present before the FN$FMS_SWAP will work. The function needs to 
be called only once per DTR session. 
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Chairperson’s Article 

Leslie Maltz, Stevens Institute of Technology, Hoboken, New Jersey 


This will be an extremely brief article this month. Instead of the usual, I would rather 
point you in the direction of the articles that follow. They are on VAX 8700 systems and some 
experiences that may be of interest. The intent of these articles is to share both experiences 
and attitudes that seem to be present in the care and feeding of the systems. As professionals 
involved in the acquisition and use of Digital’s highend computing systems, we have a need to 
know whatever possible to insure that we can support and use properly functioning, reliable 
systems. As managers and users of such systems, we need to share experiences with these and 
other systems. I encourage you to read the 8700 article, and share your experiences with 8700’s 
and other highend computing systems with all of us. We have much to gain by the sharing of 
information and experiences. 


VAX 8700 Support Experiences, Introduction 

Leslie Maltz, Stevens Institute of Technology, Hoboken, New Jersey 


Many of us are now supporting one of the popular VAXes in the 8000 series, namely the 8700. 
As the systems have not been in use for as many years as the traditional 700 series (730, 750, 
780/5, ...), they do not have a long and rich history. This lack of history means many things, but 
for the purposes of this article, I will concentrate on some issues pertaining to performance and 
reliability. This is not to imply that 8700’s are inherently bad systems; on the contrary, they are 
quite good in the environments in which many have chosen to use them. Many of us enjoy the 
benefits of such systems, but we are somewhat disappointed by the manner in which solutions to 
known problems are being handled. 

I don’t know about the distribution of systems in other geographic areas, but in the NY/NJ 
metropolitan area there are many VAX 8700 systems. Some installations have as many as 10 
8700’s. Some of us have only one. In view of the high concentration of systems in this area and 
the newness of the product, the community is in close contact. As such, when one installation 
is experiencing major problems of any nature, it is likely that others are aware of the situation. 
Such problems range from power problems to hardware support or performance issues. In this 
regard, the sense of community is great. 

Recently it became known that some 8700 systems were experiencing repeated, unexplained, 
and very unpleasant problems. At some installations some of these problems were addressed, but 
not all problems at all sites, even if the systems were known to be experiencing the problems. 
Further, there seemed to be a hesitancy by the field service organization to be open and acknowl¬ 
edge these problems, and more importantly to share the solutions. As a result a LUG (Local 
User Group) meeting was convened of the Commercial Cluster LUG to openly discuss the issues, 
problems, and solutions. This meeting was extremely informative for those in attendance, and it 
was thought that others might profit from the information presented. 

Please note that the Digital representatives from Field Service who spoke at the meeting felt 
that the problems were being addressed adequately already. As indicated (toward the end of the 
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presentation below), Digital felt that all systems in this area had been audited and informed of 
the issues. Those of us who had not yet been informed of the fact that the symptoms that.we 
had been seeing were in fact known, much less the fixes to the problems, felt otherwise. Digital 
was urged to be pro-active in sharing this list of known symptoms and their fixes with existing 
8700 sites. If you are supporting an 8700, I’d suggest that you talk with your local support 
organization to determine which, if any, of the problems have been encountered, and establish a 
plan for implementation of the remedies. It is not productive to have to live with known problems 
when fixes have been identified. Further, it is important that an open atmosphere, where we all 
have a pro-active attitude, should exist between customers and the field service organization since 
we all are working toward the same end - properly functioning, well maintained systems. 

A summary of the known problems and the solutions to the problems is listed below. The list 
was distributed at the LUG meeting and the sharing of it in this publication is with the approval 
of the Digital presenter at the meeting. Some of the solutions are not scheduled to be made 
generally available until October according to the Digital representative. As such, you will have 
to discuss the timing of implementation with your local support team if needed sooner. 


Problem 

Module 

Fix 

Remote console 

LA120 

Setup P: 2/8 

“UNIBUS” Interrupt 
(“Read Lock Timeout”) 

8700 

Microcode Rev D3 
(Cons. Rev. E) 

LAT sessions drop 

DEBNT 

Rev 1.3B 

Console disks 

Console 

VMS 

Rev E 

CWDRIVER 

18 hour crashes 

VMS 

V4.5 or SYSLOA8nn 

Various other crashes 

8700 

Memory CTL 

Rev F3 or F4 

TO DR errors 

Console 

Fix to Rev E 


[Editor’s Note: The following presentation was given by Richard Garland of Bankers Trust Co. at 
the monthly meeting of the New York Commercial Cluster LUG held at Bankers Trust Company, 
New York City, June 15, 1987. (The following summary of the presentation was prepared by 
Richard and is being published with his permission.) The meeting was attended by about 40 
members and several representatives of DEC Field Service, including the Unit, District Support, 
and the Area Customer Relations manager. After the talk, questions were addressed both to the 
speaker and to DEC Field Service.] 


VAX 8700 Support Experiences, Presentation 

Richard Garland, Bankers Trust Company, New York, NY 


I am in charge of hardware support, with the Distributed Processing Technical Support group 
of Bankers Trust. Our Group provides centralized system and hardware support to all DEC 
systems at Bankers Trust. Bankers Trust is a fairly centralized organization with all of its VAXes 
in 3 data centers in 2 locations. I would like to relate the experiences we have had in setting up 
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and operating a number of 8700 systems. We currently run 10 8700s and 1 8500. The first 2 were 
installed at our New Jersey data center in October of 1986 and the last were installed in February 
1987. We encountered a number of problems over the period from November to about March, all 
of which were eventually solved. It is our hope that the information in this presentation will be 
of help to other organizations using or contemplating acquiring this type of system. 

I will present the problems and solutions from a user’s perspective. In other words I will 
address particular symptoms which were observed even if 2 or more symptoms had the same fix. 
When the FCOs are published, these problems may be broken down differently. 

Problem 1, Remote Console 

Before describing the first problems that were encountered, it is important to describe the 
configuration we use at the Bank, with particular regard to the system console. In what I might 
call the “Normal” configuration of a VAX 8700, (A slide here shows an 8700 with the Pro-380 
console on a terminal stand next to the CPU) the Pro-380, which is the system console subsystem, 
is located adjacent to the CPU on its own stand. This configuration is typically what you would 
see at a DECUS symposium or a trade show. The distance between the CPU and the Pro-380 is 
limited be the length of the cable joining the 2, about 6 feet. In this configuration, the system 
operator is expected to use the Pro-380 to boot the system, Halt it, etc. This configuration is 
probably fine for a Lab or department with a single CPU. 

This configuration was not, however, the way we wished to use these systems in our data 
centers. Our centers typically consist of 10 - 20 VAXes in a highly conditioned room with all the 
system consoles in a centralized control room. This layout allows us to better manage the large 
number of systems and optimizes the operators’ productivity. In order to use the 8700 in our 
environment, and upon the advice of the DEC 8700 product line, the VAX’s RDC port, located 
on the Pro-380, was used as a console port, and an LA120 in the control room was wired to 
it. Appropriate commands are issued to the Pro-380 and our LA120 then becomes the system 
console transparently. (Another slide shows a sketch of an 8700 with the Pro-380 on top and a 
wire going off to a distant LA120). While the system is running, the LA120 in the control room is 
used for all commands and output. The Pro-380 sits on top of the 8700 and is essentially ignored. 

Another option which we considered, was the use of the VAX Cluster Console (a micro VAX 
which serves as the console to several VAXes simultaneously) We considered this at one time but 
decided that it does not suit our needs as we currently operate. 

The problems we encountered after setting up the first 2 systems were both related to the use 
of the remote console port. The first issue was that the console would get into various states of 
confusion as to whether the remote port were enabled or disabled and would sometimes hang the 
VAX and some times require itself (the Pro-380) to be rebooted or power-cycled. The second issue 
was that the LA120 was incapable of sending certain control characters to the console subsystem 
- notably CONTROL-P. Naturally the console lacks some essential functionality in this case: we 
could BOOT the system but we could not HALT it. We were eventually put in touch with the 
development group which wrote the Pro-380 console software and in a 3 way conference call solved 
the control character problem. The LA120 had to be set with the “P” parameter set to 2 or 8. 
Ours had been set to 1 as on all the other VAXes. They also sent us a pre-release of the console 
software rev. D (since released) which solved the problems of console confusion when enabling 
the remote port. 

Problem 2, “UNIBUS” Interrupt 

At this point in time, the 8700s were given over to the users and several projects began to build 
applications on them. There was a general impression that things were working well although in 
retrospect we know there were several problems which were not yet recognized. 
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In January of 1987 we took delivery on the fifth 8700 and immediately discovered a real 
problem. The system would crash 1 to 3 times a week with a Bugcheck: “Unexpected UNIBUS 
Adapter Interrupt” (UNEXUBAINT). This was particularly unexpected since the system had 
no UNIBUS Adapter. Field Service was able to identify this as a known problem through the 
Colorado Support Center and a fix was obtained. This consisted of a new version of the 8700 
microcode (rev. D3). This is now the released version and is part of the Console rev. E software 
kit. The new microcode was also put on the other 8700s although the problem seems only to 
have occurred on this one system. The DEC engineers refer to this as the “Read Lock Timeout” 
problem and it concerns the logic controlling the NMI bus and the BI controller. 


Problem 3, LAT Sessions Drop 


In late February, complaints from users and data center operations personnel began to show 
a pattern pointing to several problems. After many meetings with our users and with DEC we 
could recognize 2 major problems: LAT terminal problems and crashes. 

The LAT problems observed were that users sessions would drop. The configuration in use 
for most users involved approximately 150 users in our New York City Office communicating 
with 4 8700s in our New Jersey facility. The users in New York were on terminals connected to 
DECserver 100s and DECserver 200s. The New York Ethernet was connected to the New Jersey 
systems using a Vitalink TransLAN 1 , which operated over 2 T1 links. The symptom was unfor¬ 
tunately reminiscent of problems encountered in the Fall of 1986 due to Vitalink configuration 
problems. For some time users would simply say “The Vitalink just went down again” and they 
would complain to our telecommunications group. It was soon recognized that the Vitalinks were 
working properly and the problem lay in the Ethernet controller of the 8700 systems (known as a 
DEBNT). After lengthy study by one of our systems programmers, a correlation was found with 
DECnet traffic: high DECnet traffic would cause the LAT problem; LAT traffic (in itself) would 
not. An additional symptom was the presence of a high number of “System Buffer Unavailable” 
(1-2 per second worst case) when the Ethernet counts were displayed. After we had thus narrowed 
down the issue, DEC was able to determine that the DEBNT microcode was at fault (several 
VMS driver patches were first tried). A new chip set (rev. 1.3B) was sent and tested and this 
solved the problem. Eventually all DEBNTs in the bank were thus upgraded. An unexpected 
but welcome side effect was that the units performed noticeably faster with the new firmware. 
(DEC has since incorporated the firmware into a redesigned module which is now shipping. It is 
module number T1034. Older units requiring the fix will be replaced by the new module.) 

Problem 4, Console Disks 

Along with the LAT problems we became aware that the systems were crashing or hanging. 
We recognized several cases: use of the Pro-380 (say to edit the default BOOT file) would usually 
hang or cause VMS to crash. At a meeting with DEC we found that there were cases where 
the Pro-380 software and VMS would not interact properly, particularly when the Pro-380s disks 
were being accessed. This could happen in two cases: editing files on the Pro-380 (actually typing 
on the Pro) and reading/writing the disks from VMS. It had long been documented that the two 
floppies on the Pro could be used as read/write, but the hard disk (an RD53) was to be write-only 
from VMS. We found that any use of the disks from VMS, even simply reading the RD53, could 
cause problems. Using the Pro-380 to edit files likewise caused problems. DEC informed us that 
a new version of the Pro-380 software (rev. E) together with VMS V4.6 would solve these console 
disk problems. Since VMS V4.6 was (an is) not yet released, patches for VMS V4.4 and V4.5 were 
obtained as well as a pre-release version of rev. E console software (since released). With these 
fixes in place we have found that we can do all the operations that used to cause problems. There 
is still the restriction that VMS can not write to the Pro-380’s RD53. We have told DEC that 


1 TransLAN is a trademark of Vitalink Communications Corp. 
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this is an inconvenience and have been told that the restriction will be lifted in the future. At 
this time if VMS issues a MOUNT to the RD53, a message comes back “Drive is write-locked”. 

Problem 5, 18 Hour Crashes 

We also recognized that VMS would sometimes crash wit INVEXCEPTN Fatel Bugchecks 
when no one was using the Pro and no one was accessing the Pro’s disks from VMS. Curiously, 
these crashes would generally occur on 2 out of 4 systems in New Jersey at around midnight 
every night, and on 2 out of 3 systems in New York at 6 PM every evening. After analyzing a 
number of crash dumps, DEC (in Colorado) found that we had uncovered the “18 hour crash” 
bug. Apparently, 18 hours after first issuing a “SYSGEN> CONNECT CONSOLE” command 
the system would crash. It turns out that the New Jersey systems were typically BOOTed at 6 
AM each day and the New York systems are BOOTed at midnight. Our system startup procedure 
requires that a file be read off of the console and thus the curious timing was explained. The 
systems that were not crashing were running VMS V4.5. The fix was to go to VMS V4.5 (and to 
use console software rev. E which we had just started using). Since it was unfeasible for several 
of our groups to go to VMS V4.5 we requested a fix to VMS V4.4 and eventually received it. 

Problem 6, Various Other Crashes 

After carefully studying error logs over a 2 month period we noticed that a few crashes did not 
fall into the same category as the previous. The Bugcheck message were generally very obscure, 
never before seen bugs. DEC informed us that a memory controller error had been diagnosed 
which resulted in a timing problem when memory not installed at the factory was used on a 
system. It turns out that factory installed memory was matched with the controller but that 
field installed memory was not matched. The problem was very infrequent - we believe we saw 
it around 4 or 5 times in 6 months of running between 4 and 10 machines. New controllers (rev. 
F3, current rev. is F4) were sent for all of our systems. We have not seen any of these crashes 
since. 

Problem 7, Time of Day Errors 

At this point it seemed that all of our systems were running reliably. We began to receive 
complaints from our operators that the system time which came up when the system BOOted 
was occasionally wrong by a random amount. If this went unnoticed it would wreak havoc with 
file creation times, DECnet, etc. After several attempted work-arounds, DEC sent us a fix to the 
console (rev. E) software which addressed the problem. It seems that on the 8700, the Pro-380 
is the repository of the time when the CPU is down (unlike earlier VAXes which had a separate 
battery powered TODR). The Pro would fail to save the time properly when a VMS “SET TIME” 
command was issued (with no argument this is supposed to set the time back into the hard ware 
register). This fix is the only thing that was not fixed in console rev. E. and will be part of rev. 
F (not yet released). The patch is available from Field Service and should ship with currently 
shipping systems. 

Conclusion 

At this point a representative of DEC Field Service outlined procedures for solving any of 
these problems. A service call should be logged for all suspected problems. All fixes and updates 
outlined here are available immediately. Furthermore, it was stated, in the New York Area, 
all installed 8700s have been audited and known problem situations have been identified. All 
systems shipped as of this time are said to incorporate all fixes. Users were advised to use 
escalation procedures, in place, if problems are not resolved. Lou Schiavone (212-714-6746), the 
New York Area Customer Relations manager said he would be happy to converse with DEC Field 
Service from other areas on these problems. 
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Several users questioned DEC Field Service on the issue of notification to the user community 
at large of known problems and fixes. The publication of FCOs, it was pointed out, lags months 
behind problem identification and resolution. (In fact, the FCOs incorporating the fixes outlined 
above are not yet published as of the latest issue of DEC-O-LOG). 

A question on whether the information, attributed to DEC, that Local Area VAXclusters 
(Ethernet based) should not use an 8700/DEBNT as a load host, was due to the DEBNT problem 
mentioned in this presentation. DEC said they would look into that question. 


The Times They Are A-Changin’ - MARKET Going Away 

Reed B. Powell, Digital Equipment Corporation 


As part of LCG Marketing’s plans for being out of business on 30-June-1988, we are working on 
plans to dismantle system 2244, aka MARKET:: & DEC-MARLBORO, in the very near future. 
After looking at the usage of the system, which is very low, it does not seem to make sense for 
DEC to have 2 systems on the ARPAnet, one of which spends most of its time transferring PC 
utilities via KERMIT. 

As I said, the life-span of MARKET/DEC-MARLBORO is now quite short: we expect to 
remove it from active service on 30-June-1987. We are quite anxious to make this as painless as 
possible, and therefore are soliciting input from anyone who feels this will adversely impact them, 
so that we can try and make the appropriate arrangements. We are planning on retaining the 
MARKET and DEC-MARLBORO synonyms for the existing DEC20 within engineering currently 
on the ARPAnet. 

We do not expect the KERMIT library to survive this move. We do expect all current internal 
DEC users to continue to have ARPAnet access. We do not expect to retain external (to DEC) 
users on the system picking up this load. The Integration Tools Clearinghouse will remain in 
operation, but without the LCG.CUSTOMER account, whose usage has been mi nim al. 

Please send comments, etc., to myself as POWELL@DEC-MARLBORO. 

[Editor’s Note: Because many readers do not have network access to ARPAnet, you may also send 
your comments to me at any of the addresses at the beginning of this newsletter. I will forward 
them to Reed. By the time this article is published, system 2244 will be a part of history.] 
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From the INFO-VAX Mailing List 

Abstracted by: Betsy Ramsey, American Mathematical Society, Providence, RI 


The following messages are selections taken from the INFO-VAX interest group, which is a 
mailing list maintained on the DARPA Internet. These items appear for information purposes 
only. Neither DECUS nor the authors assume any responsibility regarding the usefulness or 
accuracy of the information herein. By convention, lines beginning with “>” are extracts from 
previous mail messages that are included for clarity. 


Date: Wed, 22 Apr 87 19:45:37 est 

From: decvax!unh!wfc@ucbvax.Berkeley.EDU (William F. Costa) 

Organization: Academic Services Group, UNH Computer Services 

I’m new to the NET, so I can’t help feeling a little nervous about this, my first contribution. 
However, a number of letters about defining ‘new’ commands for VMS users has struck a cord, 
so here’s my two-cents on the subject. 

At the University of New Hampshire (UNH) we’ve added quite a few home-grown programs 
as well as the usual second-party stuff (SAS, SPSSX, System 1032, etc.) Since not everybody 
uses these products, we do not automatically make them available for all users. This obviously 
helps keep the system login file a reasonable size (and duration). However, we did create one new 
command that all users get, it’s called “SETUP”. Essentially, if a user wants to access any of 
these non-native VMS programs, they simply ask for it: 

$ SETUP S1032 

This will define S1032 (System 1032) as a command for the remainder of their terminal session. 
(Those users who use such applications day in and day out can simply place this command into 
their own LOGIN.COM.) We feel that this approach makes access to these ‘new’ commands as 
easy as possible for the users who need it, while at the same time limiting the overhead for 
everyone else. We also hope that doing this helps reinforce the fact that what they have just ask 
for is NOT a normal part of VMS, but rather a tool that UNH has added. (This is also why we 
put the help information for these programs into a separate HELP library and keep the Digital 
supplied version as virgin as possible.) 

By the way, the SETUP program is dirt simple. Right now it is simply a command procedure 
that, when asked to ‘setup’ the program FRED, will search a particular system directory for the 
file “FRED.SETUP”. If the file does NOT exist, the user is told that there is no such command 
as FRED, and that they should check their spelling. If FRED.SETUP is found, it is simply 
“@’d”. In other words, FRED.SETUP is itself a command procedure that will do WHATEVER 
IT TAKES to make FRED a command for the user. (For some programs, it may mean defining 
a dozen or so logicals and inserting the command into their DCL command table. For others, it 
may be as simple as defining a symbol; “FRED :== @UTL:FRED.COM”). 

We’ve added a few other bells and whistles, but I think you get the general idea. If you have 
any more questions, please feel free to contact me directly, I’d be happy to supply the current 
source to SETUP.COM as well as documentation that we’ve written for our users about it. 
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Date: 25 Apr 87 01:02:00 EDT 

From: Greg Hamm <hamm@BIOVAX.RUTGERS.EDU> 

Organization: Rutgers Molecular Biology Computing Lab 
Subject: RE: SETUP 

Bill Costa at UNH describes their SETUP utility. I found this interesting because it’s nearly 
identical to a utility we implemented at the European Molecular Biology Lab (EMBL), for all the 
same reasons. (Actually, we borrowed the idea from someone at a British University - wonder 
how many other implementations there are?) Our version was called PREPARE (usually PREP). 

We did go through a couple of evolution cycles on the thing, though: 

The first change was that we wrote a program instead of a command procedure, because 
people usually put PREPARES in their login.coms and got tired of waiting for them. We then 
had a file (called a “prepare dictionary”) which contained a single-line command for each “prepare 
enviro nm ent”. Usually these were things like “@some.com”, but they were also allowed to be SET 
COMMANDS or single definitions of some sort. Since the things were not required to sit in one 
directory, this also gave us a mechanism to provide global access to things the systems group were 
not maintaining - we’d just point the prepare command at some user’s setup procedure, and let 
him/her do all the work. 

This worked well, but the list of environments grew, and the thing was again too slow. Finally 
we made the dictionary file indexed, and wrote a small PREPUTIL to add/remove things from 
it. This was less convenient than having just a text file, but sure was faster. As far as I know, 
this is the version they’re currently running. 

By the way, all this “we” stuff I keep saying was mainly Roy Omond - I just watched and 
made helpful noises (“It’s too slow, Roy!”). 

Whatever the implementation, I certainly agree with Bill that this is an ideal way to avoid 
defining everything for everyone. It also provides a lazy way out of the problem which occurs 
when two third-party packages define the same symbol differently. You just tell people to prepare 
only one of them at a time. (Beats workin’!) 

Who else has implementations of SETUP/PREPARE, and how do they differ from these two? 


Date: Mon, 27 Apr 87 08:54 PDT 

From: Chris Yoder <CHRIS@ENGVAX.SCG.HAC.COM> 

Organization: Hughes Aircraft Company 
Subject: RE: SETUP 

>Who else has implementations of SETUP/PREPARE, and how do they differ from 
>these two? 

We do... Though after reading about the way that other people have this type of utility defined 
there has been some serious thought about redoing the way that it works! Our’s is called SETUP, 
so in SYLOGIN.COM the DCL symbol SETUP is set to @PUB:SETUP. Currently SETUP is 
one big long command procedure with a bunch of labels. When a user issues a command like: 

$ SETUP TEX 

The DCL code fragment that they execute in SETUP looks like: 

$ on warning then goto No_Such_Setup 
$ if pi .eqs. "" then goto Show_Available_Setups 
$ goto ’pi’ 
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$ TeX: 

$ LaTeX: 

$ @TeX_Root:[Local]TexSetup 
$ if f$mode() .eqs. "BATCH" THEN goto Done 
$ define/user sys$input sys$command 
$ News/Directory TeX 
$ goto Done 

Note that this allows to point different names for the same setup at the same procedure. 
The problem with this approach is that even with abbreviated sections for each command, the 
SETUP command procedure quickly gets very long. Ours is 407 lines, and growing. It also 
contains product definitions for every system that we manage, so portions are never accessed on 
some systems. 

Personally I like the idea of having a short, simple command procedure that attempts to 
execute the first parameter passed to it. If you’re tricky, you put the setup command files in a 
directory pointed to by a logical name that is a list. Then you can put your “normal” command 
files in the “every-system” directory, and the “local” command files in the “local” directory and 
let the system look in the local directory first and the every-system directory if it can’t execute 
anything in the local directory. In some ways it’s easier to manage, commands are trivial to add 
and remove simply by adding files to or deleting them from your system directory, though you do 
end up with a whole mess of little tiny command procedures cluttering your setup directory(s). 

I’m not quite sure what to say about the issue of speed... The approach outlined above will 
be quicker than one big long command procedure most of the time, but I really have no data 
or feel for how long it takes to add another command procedure onto the stack. I’m also not 
quite certain how one would get a program to be able to execute the setup command procedure 
in the context of the current process (it’s easy enough to spawn of a command that executes the 
command file though). I don’t believe that a parent processes symbols or Command Language 
Definitions can be modified from a subprocess. 

More ideas, thoughts, and musings on this subject are welcomed! I’d love to hear how other 
people deal with this issue. 


Date: Wed, 29 Apr 87 04:09:45 PDT 

From: Frank Nagy <nagy%43198.hepnet.Cl)LBL.ARPA> 

Organization: Fermilab Research Division EED/Controls 
Subject: RE: SETUP/PREPARE 

In designing systems like SETUP or PREPARE which end up calling lots of little command 
procedures... remember that just about the SLOWEST operation DCL can do is to open a new 
file (for reading, writing or command execution). “Simple” things (a logical name or 2 and a 
symbol or 2 at most) are best grouped together to avoid this problem! For more complicated 
packages, the overhead of the file open becomes less important. However, the long dragging wait 
for LOGIN to complete can be a real pain! 


Date: Tue, 28 Apr S7 04:34:18 PDT 

From: Frank Nagy <nagy%43198.hepnet@LBL.ARPA> 

Organization: Fermilab Research Division EED/Controls 
Subject: Current (not-so modern) backup devices for VAXClusters 

>If you ask DEC for their suggested backup technology for VAXclusters 
> where you might have multiple RA81’s or SA482’s they reply TU78’s and 
>similar which cost a small fortune. 
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All the big (Cl) VAXClusters here at Fermilab have TA78 systems which are used for backups 
My group’s LAVCs fLocal Area VAXClusters) is either using RA60s (with pack-to-pack backups) 
or backing up onto (ugh) TK50s. 

>Can anyone suggest more modern equipments to solve the thorny backup 
>problem WHICH ARE RELIABLE AND PROVEN... 

In my experience, the TA78s are reliable when used primarily for backups. The main VAX- 
Cluster here has 12 TA78s which are HEAVILY used by users for reading/writing data tapes. 
They have intermittent problems with formatter hangs (discussed in a previous Info-VAX sub¬ 
mission). 

>How about some of the Megatape products I see (650Mb a cartridge??) or 
>WORM optical discs...what are big cluster sites doing now. 

One thing about TA78s is that they are fast; assuming you have a large VAX (at least 785, 
>8500 best) AND that your backup does not get dominated by disk head motion. GCR tape 
recording is a very reliable and proven technology. One major advantage of the TA78s (and any 
other tape or disk drive which emulates DEC products) is that system disk backups are easily 
done and can be restored using Standalone Backup. Consider if you use a WORM drive which 
requires a special driver; you must still make provisions to save your system disk on tape or disk 
such that Standalone Backup can restore your system disk in case of ultimate “oops”. This is, I 
think, the major problem with devices like the Megatape or ExiStore (I think this is the name 
of the recently announced 8mm tape which can store - get this - 2048 MB!). We are planning to 
add a TU81+ to our LAVC to replace TK50 backups for just this sort of reason (currently the 
LAVC has dual RA81s, soon to be a full set of 4). 

WORM disks would be nice. However, vendors seem to be concentrating on making WORM 
disks look like read/write magnetic disks in terms of the on-disk file structure and system access. 
A better and probably cheaper solution for WORM backups would be to make the WORM drive 
look like a magnetic tape. One other thing about WORM drives; their data transfer rates are 
SLOW, on the order of 200KBytes/sec for writing. This is considerably slower than current tape 
technology. 


Input Needed for New White Paper on Large Computers 

Clyde T. Poole, The University of Texas at Austin, Austin, TX 


The DECUS U. S. Chapter, Large Systems SIG, is once again sponsoring the development 
of a “White Paper” for possible presentation to Digital. This paper will concern itself with the 
large computers and computer systems of the future as seen by users of Digital computers. 

By the time this newsletter is in the hands of its readers, the SIG Steering Committee will 
have already reviewed a draft outline for this paper but input from the user community will still 
be needed. Without attempting to prejudice your input, here is what I think we would like to hear 
from you. “What should future Large Computers and Computer Systems produced by Digital 
look like?” You should not feel limited by any current Digital operating systems or computer 
architecture nor will I attempt to answer the question “What is a Large Computer?”. 

Your input is VERY much needed. Send your comments and suggestions to any of my 
addresses listed at the beginning of this newsletter under “Contributions.” 
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FROM THE EDITOR... 


For those of you who have been patiently awaiting the announcement of the OASIS (notes) system for all 
DECUS members intereted in OA, the wait is over! Our first article this month lists the phone numbers 
and information needed for you to access OASIS, find out more about it, and apply for access to Notes. It’s 
a free service so sign up soon. 

Our August issue is dedicated to the System Improvement Requests (SIR’s). First, we have Digital’s 
feedback (or responses) to the items you voted were most important. Not only did they respond to the top 
10, as usual, but also 40 more! Then, we dive right into another voting cycle for SIR’s submitted between 
San Francisco and Nashville, plus all of the ’Wish List’ items the users gave us during Nashville. Please 
take some time to read the new SIR’s, fill out a ballot and mail it in (feel free to photocopy the ballot so 
your co-workers may also vote). As you can see from reading Digital’s responses, they are listening to our 
ideas and through voting, evaluating the items we collectively feel are important. 

Regards, - Therese LeBlanc 

OA Newsletter Editor 
275 London Place 
Wheeling, IL 60090 
(312) 459-1784 

ANNOUNCING OASIS 

Many of you who came to the Nashville Symposium had the opportunity to hear about a new service for 
DECUS members interested in Office Automation - the Office Automation SIG Information System 
(OASIS). OASIS is a way for you to ask OA related questions of other users, and share your experiences 
or expertise with others. OASIS is a free (you pay for the phone call) services located on a DECUS 
MICROVAX which combines the Notes and Videotext products so that subscribers can carry on informa¬ 
tion exchanges on a variety of topics. 

OASIS is now available for your use. The majority of the introductory information and documentation will 
be found on-line once you have successfully logged in, applied for and received your account. (This is a 
painless process). 
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OASIS CONTINUED... 

To access OASIS, you may use one of four lines: 


(603) 884-1738 - 
(603) 884-1739 - 
(603) 884-1740 - 
(603) 884-1742 - 


1200 baud only 
1200 baud only 
1200 baud only 
2400 baud 


REMEMBER: THE SERVICE IS FREE...YOU PAY FOR THE PHONE CALL. 


To Use: 


1. Once you have connected to OASIS, log into the account: OASIG. 

2. You will be taken directly into VTX where you may read several pages of information on OASIS, the 
OASIG, etc. 

3. Before logging off, be sure and fill in the account request form so your account can be created, allowing 
you access to the VAXNOTES system and the OASIG conferences. 

If you have any difficulties completing these preliminary steps, please feel free to call or write: 

Joe Whatley 

OASIS System Administrator 
C/O A.C. Nielsen Co. 

375 Patricia Ave 
Dunedin, FI 33528 

(813) 734-5473 x2438 

Joe 


DIGITAL FEEDBACK TO DECUS SIR ITEMS 

The following represents some general thoughts about the System Improvement Request (SIR) process. It 
is intended to provide some insight as to how it is utilized within Digital, the guidelines we have established 
for providing feedback, and the context in which we believe our customers should view the information 
provided. 

I. The SIR process is important to Digital, we want and value inputs from our customers. 

II. The SIR list is distributed to senior marketing, product management, and engineering 
managers resonsible for planning Digital’s office products. 

III. The SIR’s are evaluated, and become part of the strategy and planning discussions for 
future releases of our products. 

IV. SIR’s tend to generate items that are "feature oriented," as a result, implementation is 
considered as part of the normal release cycle for a product. 

V. It takes time to implement good ideas. If a SIR represents a new idea, the process of 
research, specification, development, testing, and release can take a significant amount of 
time for a major development item. If work has already started on an item as part of our 
normal product development prior to it becoming a DECUS SIR, the SIR process helps to 
establish priority, and to provide additional input into implementation. 

VI. In order that we not mislead customers, both DECUS and Digital places limitations on 
discussions of future products. In general, no commitment can be made concerning specific 
enhancements to the release of a particular product. Discussions of future product direction 
are considered as part of individual customer plans under non-disclosure agreements. As a 
result, although the requests generated through the SIR process are vital to our planning, 
feedback to DECUS must often be limited. 
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VII. 


The feedback provided on SIR’s will fall into four general categories: 

1. We currently have no plans to implement the suggestion. 

2. Good idea, we will evaluate further and consider implementation. 

3. We are currently developing a capability similar to the request. 

4. We currently provide that capability. 

It is important to remember that since we are often dealing with futures, we do not suggest that our 
customers make operational plans based on this information. However, the information may be of some 
assistance to customers who are considering alternatives for investing development time in system 
modification. 

SPRING DECUS 1987 - OA SYSTEM IMPROVEMENT REQUEST 
RESPONSE 

rank # 1 
sir # 486037 
votes 203 


Provide LN03 support for WPS: proportional spacing; mixed fonts on the same page; and, 
portrait and landscape modes on the same page. 

This is a good suggestion and will be considered for a future release. Currently DECPAGE supplies this 
support through the DECPAGE proportional fonts, it does not use the cartridges supplied by the LN03. 
WPS-PLUS does do landscape and portrait together but we recommend doing it on separate pages as the 
page settings are quite different. Printer tables to support mixed fonts are also available on the DECUS 
OASIG tape. 

rank # 2 
sir # 187024 
votes 193 


Improve the facility for shared documents. 

A shared FC is available through software services assets library. This feature will be considered for 
ALL-IN-1 in a future release. 

rank # 3 
sir # 386002 
votes 188 


The Janitor function should be enhanced to include searching for expiration dates , and to 
delete those documents past expiration. 

This suggestion will be considered as we plan future releases of ALL-IN-1. 

rank # 4 

sir # 287065 

votes 179 


A new Print menu should be developed to include options such as: Cancel Print (without the 
user issuing a command from the DCL level), Pause Printer (to pause the printer before a 
specific job so that the paper can be changed), and Continue Print (to continue printing after 
the Pause Printer command has been executed). 

Good suggestion, this is all part of print queue management which will be considered as we plan future 
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releases. 


rank # 5 
sir ft 287010 
votes 174 

When printing a multi-page document, provide the capability to print selected pages or range 
of pages. 

This is clearly a desirable feature and will be considered for future releases. 

rank ft 6 
sir ft 287012 
votes 169 


Provide a supported, fully "blessed", archiving function for documents. 

This feature is under consideration for a future release, 
rank # 7 
sir ft 187004 
votes 167 

Provide greater standardization of data entry on ALL-IN-1 forms; for example, tab, return and 
down arrow are inconsistent in usage from screen to screen. 

There are some improvements on layout in V2.2 - This is part of a continual process of user interface 
improvement. 

rank ft 8 
sir # 486031 
votes 143 


Improve the multi-column composing and editing features of WPS — up to 5-6 columns (side 
by sidej of text are required. The multi-column print facility also need to be improved. 

The column cut and paste functionality from the DECMate is being considered for a future release. 

rank ft 9 
sir ft 287008 
votes 123 


Provide a shared folder facility for LDP's. 
This request will be evaluated as we plan future releases, 
rank #10 
sir ft 385034 
votes 112 


For ALL-IN-1 users, non-ALL-IN-1 users, and both, provide the ability to send, receive, and all 
of the other mail functions, regardless of whether the user is in ALL-IN-1 or not and have the 
receiver receive it whether or not he is in or out of ALL-IN-1. 

Both ALL-IN-1 mail and VMSMAIL are constantly under review. Both mail systems can send and receive 
the other’s messages. It is not likely that VMSMAIL will ever be able to perform all of the functions of 
ALL-IN-1 mail but as many features as possible are included in both. 
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rank #11 
sir # 187001 
votes 111 

Provide a facility to abort printing of a document. 

(Same as 4) will consider as we plan future releases, 
rank #12 
sir # 187016 
votes 101 

Provide a column cut and paste facility that is the same for all of Digitals Word Processing 
software. 

We are continuing to work toward consistency and increased functionality in all of our word processing 
products. We will consider this suggestion as we plan future releases of those products. 

rank # 13 
sir # 287071 
votes 99 


The editor screen width for a wide document should be "attached" to the document; therefore , 
when the editor is invoked for that document , the editor would automatically shift into wide¬ 
screen mode. 

This is considered a bug, and will be taken care of in the next release, 
rank #14 
sir # 287006 
votes 91 


Provide a facility to define which ALL-IN-1 users may access a selected document/folder; 
access should be defined as either READ or READ/WRITE. 


(Same as 2) a shared file cabinet facility is available from software 
services. This feature will be considered as we plan future releases of 
ALL-IN-1. 

rank #15 
sir # 287070 
votes 90 


Provide a document archiving and retrieval system. 

(Same as 6) will consider as we plan future releases, 
rank #16 
sir # 386043 
votes 83 

Allow the text to automatically wrap when editing , so that the user doesn't have to "advance" 
through it. 

We will consider this as we plan future releases, this is a performance consideration. 
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rank #17 
sir # 187019 
votes 81 


Provide a global search arid replace function for spell check within WPS-plus. 

We will consider as we plan future releases, 
rank #18 
sir # 187023 
votes 80 

Provide the facility for the output document of a form document to take on print format. 

We will consider as we plan future releases, 
rank #19 
sir 385017 
votes 78 

In the distribution of future ALL-IN-1 releases, when menus are eliminated or modified, 
provide a list of them so that sites with extensive customization can more easily migrate to the 
new versions. 

A very good suggestion, we will consider this as we plan future releases, 
rank #20 
sir # 287059 
votes 78 

Provide documentation on all WPS-Plus/ALL-IN-1 error messages. 

This will be considered as we plan documentation requirements for future releases. 

rank #21 
sir # 187002 
votes 75 


Provide an abbreviated Print Index facility that would displ the title and folder of the docu¬ 
ment, the creation date, and creator. 

We will consider in a future release 

rank #22 

sir # 287073 

votes 75 

The list processing output document should take the print settings from the form document . 
just as DECmate/WPS does. 

We understand this request to be the same as number 13. 
rank #23 
sir # 287067 
votes 73 


Enhance the gold-write function to allow writing to an existing document; the function could 
prompt for insert at top, bottom or overwrite. 
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Good suggestion, we will consider for a future release, 
rank #24 
sir # 287004 
votes 72 

Provide a new File Cabinet menu option that will print a list of folders, without using the 
Print Screen function. The following information should be printed: folder name, date created , 
and number of documents in folder. 

We will consider in a future release. 

rank #25 

sir # 287034 

votes 66 


Provide full functionality word processing that will be on a par level with other PC-based word 
processing packages and will also be com patible with WPS-Plus/VMS. 


Good suggestion - our strategy is to continue to enhance our word processing products. 

rank #26 
sir # 287017 
votes 66 


When WPSPlus is the default editor and the Answer (A) function has been invoked, GOLD-O 
should provide a " toggle" between the original document and answer. 


This is not easy to achieve because of the architecture of the WPS-Plus 
editor. However it is possible to do by means of a UDP very simply. 
Please ask your software specialist to show you how it is done. 

rank #27 
sir # 287068 
votes 65 


The status line which is available with GOLD-Z should be permanently displayed on the 
bottom of the screen. This would make it compatible with DECmate/WPS. 

Will be considered as we plan future releases. 

rank #28 

sir # 187027 

votes 63 

Provide an improved VAXnotes/ALL-IN-1 interface , using the Gold-Key concept. 

VAXNOTES currently supports the WPS-Plus editor. Further integration of VAXNOTES will be 
considered as we plan future releases of it and ALL-IN-1. 

rank #29 
sir # 287007 
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votes 63 


Provide the ability to change the name/title of a document without having to refile it to 
another folder or creating a new document. 

This feature is already available. 

rank #30 

sir # 287060 

votes 61 

Provide a simple to use mechanism to send the first page of a document to one paper tray of 
a printer and the rest of the document to the other paper tray. 

Improvements to the automatic sheet feeders are planned for the future releases. 

rank #31 
sir 485004 
votes 60 


Make the List function quit deleting trailing blanks and special characters; it also mishandles 
some Regis commands. 

Deleting of trailing blanks considered a bug. Improved Regis and Sixel support is being planned for future 
releases. 

rank #32 
sir # 385049 
votes 59 


Provide tools, support and/or clues on interfacing and integrating non-Digital layered products 
to ALL-IN-1; such as, Telegraf, 1032 and SAS. 

Information on integrating applications with ALL-IN-1 can be found in the Applications User Guide. 
Software Services consulting and DECUS resources are also available for help on this subject. 

rank #33 
sir 287011 
votes 58 


Provide a Telephone Message Pad (TMP). When a secretary is answering the phone, they need 
to access the TMP from any screen , including the Interrupt screen. The information on the 
TMP should be that which appears on a standard Telephone Message Pad. ALL-IN-1 should 
have a " IMP-flag Waiting " like "Mail Messages Waiting"; and, the TMP message should be 
readable from a GOLD-Key function from any screen. 

This is a good suggestion. We will be consider the possibility of including such a feature in a future release. 

rank #34 
sir # 485033 
votes 34 


Provide a new service: computer conferencing/bulletin board. 

The combination of VAX VTX and VAXNotes can provide computer conferencing and bulletin board 
capabilities now. 
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rank #35 
sir 385010 
votes 35 


Provide a full scale office work station for the IBM PC, something on the order of the 
DECmate office workstation except better , ie. more functions downloaded into the PC, the 
calendar downloaded to some extent on the PC, allow menus to be modified on the VAX and 
download them onto the PC. 

To some extent this is the definition of PC ALL-IN-1 minus the 
CALENDAR/VAX menu modification, this request will be considered as we 
plan future releases of PC ALL-IN-1. 

rank #36 
sir # 287031 
votes 55 


AU WPS-Plus versions, regardless of hardware environment, should have the same 
functionality and user interface. 

Thus our continuing strategy is to make the user interface and functionality of all WPS-PLUS products the 
same. This is not possible in all situations due to operating system as well as hardware limitations. 

rank #37 
sir # 386013 
votes 54 


Provide a printer option that does not display a menu, but rather goes directly to the users 
default printer. 

This will be considered for a future release but can be achieved now through customization. 

rank #38 
sir # 287066 
votes 54 


Enhance the RV (Receive from VMS) function to allow the use of wildcards. 

We will consider for a future release but it is not currently achievable 
with the existing design of WPS-Plus. 

rank #39 
sir # 287036 
votes 50 

Provide a Spell Check function. 

DECSPELL provides this function for all of our word processing systems and is available today. 

rank# 40 
sir 287024 
votes 49 

Allow for "Standing Meetings": When the option is invoked, parameters could be specified for 
dates and/or number of days/weeks. 

We are evaluating the functionality of time management and will continue 
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to enhance future releases. 


rank #41 
sir # 287005 
votes 49 


Enhance the document transfer function for importing VMS files to the ALL-IN-1 file cabinet: 
provide a prompt to query if the VMS file should be deleted or not after it is imported. 

This is a good suggestion, we will consider it as we plan future releases. 

rank #42 

sir # 287015 

votes 46 

Provide a feature to automatically delete all documents from the read and outbox folders after 
the documents have reached a specified age. The age would be set by the ALL-IN-I System 
Manager or by an option on the individuals file cabinet. 

Will consider as we plan future releases. 

rank #43 

sir # 386011 

votes 42 


Provide a "secret" classification for mail; this type of mail would require greater security than 
"confidential and the secretary would not be able to read it. 

Will consider as we plan future releases of our mail products. 

rank #44 

sir # 486002 

votes 42 

Provide an option to allow a user see the status of mail messages that have been sent but not 
yet read. Message status would include the title of the message and the addresses who have 
not read the message. 

This is a very good suggestion and we will consider it as we plan future 
releases. 

rank #45 
sir # 287035 
votes 40 


A Copy function should exist to allow the copying of documents from one drive to another. 
Currently, approximately six steps (including DOS commands) are required to accomplish this 
operation. 

This feature can be found in PC ALL-IN-1 today, 
rank # 46 
sir # 287023 
votes 38 

Allow mail messages to be filed in the users directory (personal storage) and delete the 
pointers to the share file. The current File Text and File Message facilities are not acceptable. 

Filing mail messages in the user’s directory would make them editable and would therefore dilute the 
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integrity of the mail message. It is possible to accomplish the effect you are looking for with todays 
product. 


rank # 47 
sir # 385011 
votes 36 


Provide an indication on the ALL-IN-l screen or menus of the load on the system; when the 
system is heavily loaded, the users don't mind waiting a little longer, if they know it will take 
a little longer. 

This function could be provided through customization with todays product. We will consider for inclusion 
in the standard product as we plan future releases. 

rank #48 
sir # 287044 
votes 36 


Provide the ability to Get a page or specified range of pages from another document , rather 
than the entire document. 

We will consider for a future release. There is a workaround to this problem that can be accomplished by 
utilizing library document techniques. This subject was discussed by Jack Gilmore during his "Power of 
GOLD KEY Editing" presentation. 

rank # 49 
sir # 187018 
votes 36 


Give LN03 printing capabilities on the VAX as on the DECmate. This capability should 
include the facility to stop the print job and to stop before each page. 

Will consider as we plan future enhancements to the print queue manager. 

rank #50 

sir # 385009 

votes 36 


Provide the ability to manage the ALL-IN-1 system files separately from the janitor process. 
By breaking these two functions apart , the amount of dedicated system time is minimized. 

Will consider for a future release. 


TIME TO VOTE ! 

E. Catherine Ditamore 
ARA Services, Inc. 

Once again, it’s time to vote on the SIR’s! The System Improvement Request (SIR) Process provides us. 
Digital users, with a mechanism to help guide the development of Digital’s Office Automation (OA) 
products. SIR’s are submitted by you and then prioritized through a tally of your votes on the SIR’s. It is 
this prioritized list that Digital will review in order to prepare their response, which will be given at the OA 
Wish List Session in Nashville. For those of you not attending the symposium, you’ll find the response 
printed in the OA SIG Newsletter after symposium. 

In order to give Digital an adequate amount of time to form their response, you need to vote TODAY! Any 
ballots received after OCTOBER 12 cannot be counted. You’ll find the ballot in the "tear-out" section at 
the end of the newsletter. 
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The list of SIR’s was compiled from three sources: completed SIR forms (like the one in the "tear-out" 
section at the end of the Newsletter); wishes submitted at the OA Wish List session during symposium; 
and, SIR’s to which Digital has not yet made response but which received votes during a prior ballot. 

The SIR’s are grouped below by category, to simplify your review. You have 100 points to allocate among 
the SIR’s on the ballot, although you may not give any one SIR more than 10 points. You may assign the 
point values in either a positive or negative sense: a high positive value would strongly encourage change, 
and a low negative value would discourage the change. For example, if the positive points total 80 and the 
negative points total 20, the allowed 100 points have been fully utilized. 

Remember, only one ballot per DECUS member will be accepted! 

ALL-IN-1: GENERAL ENHANCEMENTS 

386003 The VAX-11 FMS Translator License should be included with the ALL-IN-1 layered product. 

187003 Provide updates to the ALL-IN-1 documentation kits from version to version, rather than 

complete new documentation kits. 

187005 The contents of a document should be consistent, regardless of its origin. A document 

created in Electronic Messaging appears to contain both header and text; therefore, when 
such a document is transferred, both the header and text should be transferred. The fact 
that only the text is transferred is very difficult to explain to an ALL-IN-1 user. 

287002 Provide the ability to save rulers for Electronic Messaging documents, as in WPS-Plus. 

287003 Implement PC MEM as part of the base Action Item product; in the past, it has been an 

unsupported function that enhanced the Calculator function. 

287009 In the Nickname Management Subsystem, change the "Mail Address" field to "Username" 

to minimize confusion. 

187026 When Spell Check is selected from Electronic Messaging (EM), ensure that it returns to the 

EM menu, not Word Processing. 

387001 Have the print formatter recognize and correctly interpret the special print characteristics 

embedded in COBOL/FORTRAN generated print files. 

387002 Provide more ways to Index documents, e.g. using a SINCE or BEFORE qualifier or using 

a SEARCH string. 

387003 When using Spell Checker, EDT documents should not be converted to WPS. 

387004 Provide a message indicating that the Spell Checker has finished. 

387005 Expand the length of the Nickname Management name field so that it can be used to assist 

in accessing public networks. 

387009 Improve the facilities for managing mail distribution across a multi-node network, e.g. users 

shouldn’t have to know what node another user is on. 

487001 Allow the user to "blank out" the ALL-IN-1 screen via one or two keystrokes. 

487002 Digital should establish a corporate philosophy that all software will require the same 

keystrokes to perform similar functions, and establish and publish a User Interface 
Standard. 

487003 Allow multiple users to log into and work in the same ALL-IN-1 account (same Username), 

concurrently, while maintaining the integrity of the data files. 

487004 Revise the menu operation to allow task selection by cursor key controlled, highlighted 

selection; pressing the first letter of the desired function selection and return, or a function 
key, would reduce keystroke requirements — similar to the Spell Checker. 
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487005 When viewing the display of an Index request, allow the user to scroll backward as well as 

forward. 

NEW ALL-IN-1: FEATURES AND FACILITIES 

185002 Provide the capability for system-wide nicknames. 

185025 Provide better integration of ALL-IN-1 with the following products: DECslide, DECgraph, 

and DECalc. 

385013 Provide improved security and protection features for ALL-IN-1, something on the order of 

allowing users to see the menus and the selections on them, but not be able to execute the 
individual functions unless they have been authorized to do so. 

385031 Improve the packaging of OA products. With an ALL-IN-1 system there are a large number 

of products that require coordination of different versions for compatibility. They should all 
be bundled together so that the user can receive one big package in the mail and know that 
they have everything needed to bring up a new version. 

187007 Provide ALL-IN-1 Error Message Documentation on DSIN. 

187029 Provide an automatic interface between ALL-IN-1 and CMS; provide the ability to develop 

forms in CMS. 

387006 Provide TPU support. 

387007 Provide a statistical analysis that would allow the system manager to monitor ALL-IN-1 

user activity. 

387008 There should be a User Profile option to provide for Auto Delete of Return Receipts. 

387016 Provide a Speed Read facility that allows you to Read New Mail messages, but does not 

return to the E-mail menu after reading each mail message. 

387017 Provide a facility that will notify you at log in or log out that you have unsent Mail messages 

in the CREATED folder. 

387018 Allow Mailing of an entire Folder, and then filing of that folder without reading through 

every document in the folder. 

ALL-IN-1: SYSTEM AND SYSTEM MANAGER FUNCTIONS 

185004 Provide the ALL-IN-1 system manager with the ability to manipulate mail messages. 

185023 Include an additional 80-bytes in the user profile for customer specific use. 

185029 Provide a conversion utility telling you what’s been changed in your current ALL-IN-1 

system. 

185033 The Atlanta Hot Line should provide comprehensive user support. If the Atlanta Hot Line 

cannot answer a question and feels it is a responsibility of Colorado Springs, Atlanta should 
contact Colorado directly and pursue the problem with Colorado, rather than tell the cus¬ 
tomer to call Colorado. 

385014 Provide additional development tools to aid in development of ALL-IN-1 applications, such 

as cross-reference utilities. 

385042 Recognize the ALL-IN-1 script facility or language as a language and support it as a lan¬ 

guage, with the language standards. Also, provide a TPU interface so that we can get past 
the SYNTAX and get to the application building. 

485016 Provide a function (OA$SYM-DELETE) to delete symbols from the permanent symbol table. 

386005 The ALL-IN-1 documentation set should include both WPS-Plus and DECPage documenta¬ 

tion. Also, there should be a documentation index for WPS-Plus and DECPage. 
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486008 

486013 

187008 

187009 

287001 

287013 

287014 

387010 

387011 

387012 

387013 

487006 

487007 

385021 

485001 

485009 

485010 

485014 

386023 

486001 

187012 

187022 

287016 


Provide the ability to run ALL-IN-1 user main processes at a higher priority (than other 
users), while any ALL-IN-1 user sub-processes would run at the normal (default) priority. 

ALL-IN-1 should support the IBM PC/XT/AT printer port; i.e. the user should be able to 
select PORT IBM like PORT LA50 can be selected. 

Provide an ALL-IN-1 Guide to Development for new ALL-IN-1’ers. 

Provide additional script functions for string manipulation, similar to DCL Lexical 
Functions, except without having to use DCL. 

Provide a script function that is equivalent to a PASCAL "case" statement. 

Provide the capability to READ, MODIFY, and CREATE/WRITE text DSAB’s that are 
compatible with ALL-IN-1 DSAB’s; this would allow for the complete manipulation of docu¬ 
ments. This facility should be documented in the APR manuals. 

Provide technical ALL-IN-1 Training, ANYWHERE (Ed. Services, DECUS, etc.)! It should 
consist of Introduction to Scripts, Intermediate Scripts, Advanced Scripts, etc. 

Provide an easy way to change an ALL-IN-1 username. 

For sites running non-homogeneous clusters, provide a facility (for use by the ALL-IN-1 
manager) that allows mail messages that have been delivered to the wrong node to be 
redirected. 

Allow the Carpenter facility to run on a subset of the ALL-IN-1 system, e.g. on a crashed 
disk, so that the system can be restored quickly, rather than taking the many hours required 
to rebuild the entire system. 

When deleting an ALL-IN-1 user, the entries in PENDING.DAT and MEETING.DAT 
should also be deleted. 

Provide menu-driven system administration functions (such as backup, queue management, 
etc.) for non-technical VAX environments, similar to A-Z Systems. 

Provide a tape backup and restore facility for all documents in one ALL-IN-1 folder. 

ALL-IN-1: ELECTRONIC MESSAGING 

Upgrade the Mail function "Delete" with confirm and no-confirm options. 

Provide some kind of audit trail, notification to a user or duplicate messages indicating that 
something was sent to him and auto-forwarded. 

An option is needed to present expansion of distribution list or not, as subscribers are 
handled, since lists of names in excess of 20 are cumbersome. 

Names of mail-format BLP’s (i.e. MAILMEMOl.BLP) are hardcoded into ALL-IN-1. They 
could be logicals and therefore changeable. 

Add an option to allow a user to get a list of the sender and all addressees at the MAIL 
ANSWER prompt. 

Provide the ability to request Return Receipts from selected users, rather than all recipients 
of a mail message. 

Provide a user-selectable default for Received Receipts and Read Receipts; currently, NO is 
the default and YES must be selected on a per document basis. 

Provide a menu option: Print INBOX. 

Save the default print settings in Electronic Mail messages, rather than forcing the user to 
set them each time. 

Provide the ability to see which Electronic Messages you have sent that have been READ, 
without having to use Read Receipts. This function would be similar to the Message Search 
(MS) function from ALL-IN-1 Version 1.3. 
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287018 Expand the Current Item Block to include the name of the sender of the message. 

287020 Allow messages to be deleted before they have been read. 

287021 Expand the mail header on "answer" messages to include a reference to the title of the 

document being answered. 

387014 Provide the ability to mail spreadsheets and executable images (binary files). 

387015 When Filing an Attachment, if there is only one attachment, don’t prompt for which attach¬ 

ment should be filed. 

487008 For the ANSWER function. Paper Mail recipients should be identified by name, not just 

"Paper Mail". 

487009 The recipient of a message should be notified who the message is from and that a Return 

Receipt was requested. The recipient should then have the option of not reading the message 
at that time, so that the Return Receipt will not be generated until it is read. 

487010 All Paper Mail should print on the users default printer, NOT the system printer. 

487011 In order to save time and keystrokes, there should be a User Profile Option that will cause 

the user to be prompted at the end of message creation, message attachment, etc. for 
immediate sending (with the User Profile Option specifying Y or N). 

487012 The Return Receipt function should not create a document in the reader’s OUTBOX folder. 

ALL-IN-1: TIME MANAGEMENT 

287025 Provided the ability to make duplicate/recurring calendar entries, i.e. Meetings, 

Appointments, Reminders, Actions Items, and To Do Lists. A single screen should be used 
to make the duplicate/recurring entries. 

287026 All Time Management facilities should use the same entry screen. This would be consistent 

with a user having a single calendar page for a day. 

287028 In Time Management Action Items, provide the ability to edit the class or item. 

287029 In Time Management To Do Lists, provide the ability to print and view the items in priority 

sequence. 

387019 Provide a Multiple Delete/Purge option for Action Items, Reminders and To Do’s, similar to 

the facility in Meetings and Appointments. 

387020 Allow Calendar Access (i.e. Management, Two Calendar Access, Meetings) to work across 

nodes. (Note: Multiple nodes, connected via DECnet, can be located in the same building.) 

387021 Provide a Set Owner facility for Action Items and Reminders. 

487013 Improve the Index facilities. Allow selection of all meetings/appointments from a specific 

date forward in time. From that index the user should be able to select the day to be worked 
on and be able to go directly to the Advanced Calendar function. 

487014 If an appointment is scheduled within the bounds of the hours specified in the user profile, 

the AM or PM notation should be optional, e.g., from 8 to 12 should assume 8AM to 12PM. 

487015 Replace the Display Events and Print functions for Weeks and Months Schedule with 

something more similar in format to the Days Schedule. And, rather than have three menu 
entries (day, week, and month) have a single menu entry that allows the user to specify the 
number of days to list. 

487016 On the Advanced Calendar display, the selected appointment should be highlighted so the 

user can easily see which appointment would be edited, deleted, etc. 

487017 In the Advanced Calendar function, instead of using the SEL function, the user should be 

able to position the cursor on the appointment to be operated on and then press the desired 
function, such as D (delete) or E (edit). 
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487018 

487019 

487020 

487022 

487023 

487024 

487025 

487026 

487027 

487029 

385033 

485049 

485056 

386009 

486029 

187015 

187020 

187021 

287030 

387022 

387023 

387024 


An alternate date format should be provided in the form MM/DD/YY. 

The cursor movement keys should be enhanced to allow the right arrow key to move forward 
one day and the left arrow key to move backward one day. 

Prior to scheduling a meeting, a check of the attendees calendars should be made to ensure 
that they don't already have an activity scheduled. 

The meeting scheduler should have the option of being included as a meeting attendee. This 
will allow the secretaries to schedule meetings from their own account, rather than from 
their managers' account. 

Eliminate the To Do function as it is too similar to the Action Item and Reminder functions. 

Add a time field to Reminders so that the user can be prompted while logged on rather than 
only at the beginning of the session. 

Replace the Week Print function for Reminders and Action Items with the format used for 
Day Print. 

For Action Items, provide a Print function that gives a sequential list by action class and 
date of all open and/or closed action items between two dates. 

In Action Items, there is an action item class and item. A non-unique action item should be 
allowed within an action item class. (Example: If the class is Budget, it would be helpful to 
have an item of Quarterly Report appear four times within that class.) 

Add a 'tentative meeting scheduled’ status. This should appear on the user’s calendar until 
an attendee accepts or declines the invitation to a meeting. (This should also appear when 
the SCAN function is used.) If the meeting scheduler cancels a meeting, the 'tentative 
meeting scheduled’ status should be removed. 

WORD PROCESSING: GENERAL 

Provide better journaling in WPS-Plus so that a little bit more of the document is left when 
the system crashes and comes back. 

Allow all PC’s to transfer files and WPS documents to ALL-IN-1, Rainbow and P/OS, as 
part of user-friendly application. 

Enable DECmates, Rainbows, PRO’s and anything else running WPS-Plus to directly ex¬ 
change documents. 

ALL-IN-1 should support either WPS or EDT, but not both. 

Provide an index function that will work with both WPS-Plus and DECPage. 

Provide a prioritized To Do List within WPS-Plus. 

Provide an auto-index function for a document within WPS-Plus. 

In WPS-Plus List Processing, provide the ability to use multiple forms. 

The location of the NEW PAGE marker should be consistent in List Processing Form 
Documents. Currently, the location differs between DECmate WPS and WPS-Plus/VMS 
documents. 

In WPS-Plus, when the user moves past the bottom or top of the document, "any key" must 
be pressed in order to continue. Change the function to recognize any Gold-key or arrow 
sequence as alternatives to the "any key to continue". 

The status line should reflect the correct line spacing when using double or line-and-a-half 
spacing. 

Make the Footnote Editor work the same as WPS-Plus, in terms of size, editing features, 
etc. 
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487030 

487031 

487032 

487033 

287038 


485055 

486023 

287037 

287039 

287043 


287046 

287047 

287048 

287049 

287052 

487034 

386059 

287032 

487035 

487036 

487037 

487038 

487039 

487040 

487041 

487042 

487043 

487044 


Provide a status line for cursor position and insert/overstrike status. 

Display the ruler at the top of the screen all of the time. 

Provide a small reference card that can be placed next to the terminal to prompt the user on 
commonly used functions. 

In the two dimensional editor, provide the ability to draw diagonal lines. 

Allow for multi-level indents. Currently, only one line can be indented with the word wrap 
tab (W). 


WORD PROCESSING: WPS-Plus/PC 

Provide the WPS-Plus’s DX/DT option on the Rainbow. 

WPS-Plus/PC should be more like WPS/DECmate — there are differences in the user 
interface, keystrokes and functionality. 

Provide the ability for print functions to occur in the background. 

Provide support for Overstrike Mode, rather than just Insert Mode. 

Allow more flexibility with UDP’s: the ability to insert a Pause instruction to allow for more 
input of variable information; the ability to go outside WPS-Plus/PC to DOS; or, the ability 
to name the keystroke or associate a comment with it (in order to determine its contents and 
use without going into edit mode and displaying the contents). 

Provide more support for printers and simplify the support for printer tables. (Horizontal 
and vertical movement could be more easily defined by using a horizontal or vertical motion 
index and having the table calculate the various pitches.) 

Provide the ability for proportional printing on printers that support it. 

Implement multiple paste buffers so that you can cut and paste more than one item at a 
time. 

Develop a "hot-key" to DOS to allow simple DOS commands to be executed without exiting 
WPS-Plus/PC. 

Allow documents to be stored in File Cabinets. 

Incorporate the Spell Checker into the Rainbow Office Workstation. 

WORD PROCESSING: WPS/DECmate 

Allow a special key on the DECmate that would print "bullets" that are filled in. 

New WPS keycaps should be available for consistency with the new functionality available in 
Version 2.1. 

Provide multiple paste buffers. 

A Gold Quit option is needed. 

Provide a Widow/Orphan option. 

Allow for double underline. 

Allow editing to occur in View mode. 

Provide for auto-hyphenation. 

Provide a facility for automatically creating an Index for a document. 

Provide a facility for automatically creating a Table of Contents for a document. 

Provide a facility for paragraph numbering. 

Allow for Line Drawing. 
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487045 Provide a Gold Write facility similar to that of WPS-Plus. 

487046 Current Text Size should automatically be adjusted according to the document’s page size 

and top and bottom margins. Or, the Current Text Size should be located on the Print menu 
instead of the Editor’s menu. 

487047 Simplify the use of multiple columns/tables, especially when tables are more than one page. 

487048 When using the Delete option, provide the ability to queue several documents at one time, 

instead of individually. 

487049 Change the status so that the line number of each page is displayed when scrolling 

backwards. 

487051 Provide an auto-rewrite facility. 

487052 Allow the user to work with a copy of a document, not the original. 

487053 Provide a statistical column layout feature. 

487054 Allow for automatic column centering for column headings. 

487055 Enhance the Gold Get option to allow specification of pages within a document or all of the 

document. 

487056 When printing, allow several non-consecutive pages of a document to be queued at the same 

time. 

487057 When doing Reset Page, allow any specified page to be printed. 

487058 Provide an ETHERNET interface to the DECmate, similar to that for the IBM PC’s. 

WORD PROCESSING: WPS-PLUS/ALL-IN-1 

287061 Allow WPS-Plus to support the escape <ESC> character, as EDT does; this would implic¬ 

itly allow users to support their own non-Digital printers. 

387025 The Gold-Get facility of WPS-Plus should retain the rulers of an E-mail message. 

387026 Make WPS-Plus display text correctly when Mail Notify and Broadcast Messages are 

received. 

WORD PROCESSING: WPS-PLUS/VMS 

187025 Remove the ALL-IN-1 references (e.g. scripts) from WPS-Plus/VMS. 

287062 WPS-Plus/VMS does not require a Right margin when rulers are defined; a Right margin 

should be required. This is inconsistent with the other WPS products and can cause prob¬ 
lems when editing the document. 

287063 The Index function in WPS-Plus/VMS should display the VMS file specification for each 

document. 

287064 The Index function in WPS-Plus/VMS should display the VMS file size (in blocks). 

287069 Provide procedures that will reorganize (and optimize) the WPS system files; this function 

should ensure that each user’s default settings are preserved. 

MISCELLANEOUS 

185019 Provide full intelligent modem support, including looping and if-then-else capabilities. 

485058 Document header formats should be identical for ALL-IN-1, DECmate and Rainbows so that 

a document transfer will retain keywords, subject, author, etc. 

386025 Provide a simple mechanism for easily retrieving VAX-11 Datatrieve reports. 

386065 The LN03 should not produce controller errors every time pages that are more than 90 

characters wide are sent to it. 
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386067 DECSpell’s IGNORE function should not be case sensitive. 

187028 The ALL-IN-l/Message Router interface should be better integrated and easier for the 

System Manager to utilize. 

187031 Unbundle the PC/ALL-IN-1 software. 

187034 Enhance PC/ALL-IN-1 to provide better access to applications running under ALL-IN-1. 

287076 Develop a "gold" keyboard for the Macintosh. 

387027 Increase the amount of information provided by the Message Router Manager Utility about 

mail messages, e.g. name of sender, name of receiver, etc., in order to simplify problem 
tracking and resolution. 

387028 Develop something that provides proportional font printing. The current products are not 

adequate: font cartridges do not provide correct tab alignments and DECPage is not a viable 
alternative since "what you see is not what you get". 

387029 Allow documents to be cleanly printed on non-Digital printers which are attached to the 

workstation; currently, control codes print in addition to the text. 

387030 On a non-homogeneous cluster, provide the ability to deliver mail messages between the 

multiple systems without using the Message Router. 

387031 Support double underline and change bars in DECPage. 

487059 Provide a DISOSS Bridge (Gateway) to DISOSS Distribution Services for RFT documents 

and Binary (PC file type data) File mail capabilities. 

487060 The LAI00 printer should have the capability of printing double underscores. 
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(THE (LINKED LIST)) 

The Newsletter of the DECUS Artificial Intelligence 
Special Interest Group 

. . It’s The Real Thing" 

Vol. 3 No. 5 August 1987 
From The Editor: 

As this issue of (THE (LINKED LIST)) shows, the past several months have brought a 
deluge of Al-related hardware and software announcements. Perhaps the most significant 
development in the Digital community is the recently announced round of price cuts on 
VAXstation 2000 systems. Taken in conjunction with the growing number of expert 
system shells that have been ported to VAX systems, the price cuts may well portend the 
acceptance of low-end VAX systems as industry-standard AI delivery platforms. 

Digital’s competitors, however, won’t sit idly by as users discover that they can purchase 
VAX performance at personal computer prices, so it’s likely to be an interesting summer 
for artificial intelligentsia and mainstream computer users alike. Be on the lookout for 
next month’s newsletter, which will hopefully provide an after-action report on the AAAI 
conference held in mid-July in Seattle. 

As always, (THE (LINKED LIST)) welcomes your articles, comments, hints and sug¬ 
gestions. Send your contributions to DCS user SHANNON or mail them to me at the 
following address: 

Terry C. Shannon 
Digital Review 
800 Boylston Street 
Suite 1390 
Boston, MA 02199 
(617) 375-4321 

DIGITAL LAUNCHES SUMMER WORKSTATION OFFENSIVE 

By Terry C. Shannon 

MAYNARD, Mass. — When is a PC not a PC? When it’s a VAX. In a mid-June announce¬ 
ment that caught analysts and competitors by surprise. Digital Equipment Corporation 
fulfilled Ken Olsen’s promise to offer a VAX family whose price and performance span a 
thousandfold by debuting a VAXstation 2000 equipped with a 15" monochrome monitor 
and a PC-like pricetag. 

Not content to deliver VAX performance at PC prices. Digital unveiled two color 
VAXstation 2000 systems and dramatically slashed the list prices of the entire 
VAXstation 2000 family. 


Digital vice president Jack Shields claimed that the low-end VAX family is a viable 
alternative to 80386-based PCs and workstations. "Today’s aggressive announcement 
takes workgroup computing far beyond the capabilities promised for 32-bit PCs," he said. 

The vanguard of Digital’s assault on the PC price point is a new 15" monitor available in 
both monochrome and color versions. The new monitors cost about half as much as their 
VR260 and VR290 counterparts, yet provide the same 1024-by-864-pixel resolution as the 
19" monitors. 

Scheduled for December shipment are a diskless VAXstation 2000 system equipped with 
the new 15" monochrome monitor as well as a diskless workstation whose 15" color 
monitor will display four planes of color graphics. 

A color graphics VAXstation 2000 configured with Digital’s 19" VR290 monitor will be 
available in October, the company said. In addition, the price of the 19" monochrome 
VAXstation 2000 has been reduced 48 percent. The monochrome system is shipping in 
volume with 30 to 60 day lead times. 

All of the low-end VAXes come equipped with 4MB of memory, an Ethernet adaptor, 
monitor, mouse, keyboard and single-user software licenses. VMS, VAX workstation soft¬ 
ware (VWS). DECnet and LAVC licenses are supplied with systems running the VMS 
operating system. Ultrix workstations include UNIX workstation software. X-Windows 
and Digital’s port of Sun Microsystem’s Network File System (NFS) software. Also in¬ 
cluded are C, VAX C, Fortran 77 and Pascal compilers. 

Industry observers contend that the June 16 announcement reflects Digital’s plans to take 
the high ground in the workstation arena by preempting the forthcoming onslaught of 
80386-based PCs. "DEC’S announcement marks the beginning of the ’low-end wars,’ said 
Don Brown, an analyst with D.H. Brown and Associates in Tarrytown, NY. 

Brown contended that Digital’s repricing is aimed at IBM’s recently unveiled PS/2 per¬ 
sonal computer and its 80386 chipset. "We are concerned with hundreds of thousands of 
units, not tens of thousands. This is 80386 territory; not traditional VAX space," he said. 

"At the low end, there’s very little profit, but a great opportunity exists for market 
expansion," Brown explained, adding that Digital can harvest the profits later when cus¬ 
tomers upgrade to larger VAX systems. "DEC’S philosophy and approach is far superior 
to IBM’s from a financial standpoint," Brown added. 

While applauding Digital’s low-end strategy. Brown noted that the expanded VAXstation 
2000 lineup still suffers from the absence of DOS compatibility. "If DEC offered a 
workstation that runs MS-DOS in a VMS or Ultrix window and price [the product] right, 
they would have a good 80386 alternative," he said. 

Observing that the VAXstation repricing gives Digital a golden opportunity to capture the 
front end of the engineering workstation market. Brown said that the firm must move 
swiftly to exploit its position. "This is DEC’s last shot at the low-end workstation market. 
The window of opportunity will close when 80386-based software begins to ship in 
volume," he concluded. 
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Fred Cohen, an analyst with L.F. Rothschild in New York City, agreed with Brown’s 
observations. Cohen noted that Digital is using the same pricing gambit that Sun 
Microsystems adopted when IBM debuted its PS/2 computers last April. 

"Sun cut the price of its Sun/3 workstation line to deter VARs from being tempted by the 
PS/2. DEC is adopting the same approach," Cohen said. Rather than try to hide behind 
proprietary VAX/VMS technology, Cohen maintained. Digital is meeting the competition 
head-on. "The repricing strategy will help DEC obtain more VAR agreements and place 
the firm in direct competition with Sun, Apollo, Apple and IBM," the analyst said. 

ARTIFICIAL INTELLIGENCE AND DATABASES 

By Becky Selke 

Artificial Intelligence and Data Base technology are both receiving a great deal of atten¬ 
tion. Many researchers see that an integration of these technologies would reap benefits to 
both disciplines. This article examines the potential uses of the combined technologies, the 
benefits of combining the technologies, and some of the approaches being examined to 
bring the two together. 

As AI applications continue to grow, the knowledge bases that store the knowledge grow 
as well. There is an increasing need within the AI community to find more effective 
mechanisms to deal with these larger data bases. In addition, issues of sharing informa¬ 
tion, security of information, and archival of information are becoming increasingly impor¬ 
tant. Each of these issues has been addressed in the field of data bases. 

Additionally, the field of AI can contribute the ideas of natural language interfaces and 
deduction to the data base field from the standpoint of user query processing. It has been 
noted that both Prolog (a popular AI language) and relational data bases rely on first order 
predicate calculus for their foundations. This suggests that there may be a basis for using 
the two in conjunction with each other. Finally, many of the applications that could benefit 
from the use of AI techniques operate with huge existing data bases. For these systems to 
work properly, they must be able to access the data in these data bases. 

The data base field can benefit from work in AI as well. There has been a great emphasis 
placed on letting the end user directly access the information in the data base so reports 
can be generated quickly. The query languages currently are far too cryptic for the "aver¬ 
age" end user to comprehend. Thus, the use of natural language front ends is being 
heavily investigated. There is also a problem in dealing with data bases in trying to get out 
all of the information in the data base, both that information which is explicit and that 
which is implicit. For example, a geneology data base contains information about the 
relationships between specific people. Inferences can be drawn to determine additional 
relationships. Additionally, rules could be placed in the data base itself to aid in this 
inference process. Adding deduction capability would allow more information to be gleaned 
from existing data bases. Finally, some intelligence could be used in determining if a given 
query "makes sense" to give more reasonable responses to user queries. In these ways, 
research in AI can have a positive impact on the field of data bases. 

So, how do we go about combining the fields of AI and data bases? There are several basic 
approaches: 


1) Add an inference engine into an existing DBMS 

2) Add a DBMS into an existing AI system or language 

3) Write a new system incorporating both technologies 

4) Allow "call out" access to data bases from AI languages 

While alternative 3 will obviously give the best result creating an entirely new environ¬ 
ment from scratch ignores all the work to date, and requires a massive investment in time 
and money. Alternative 4 does not address the more basic problem of allowing a dynamic 
rule base and knowledge base to be archived. It would provide for the storage of processing 
information in a data base, but the requirements go much deeper into the AI systems than 
that. 

This leaves the alternative of adding a DBMS to an AI system or vice-versa. The choice 
here depends more on the application. If it is primarily a data base application which is 
accessible from a conventional language, the addition of an inference engine could be 
accomplished to allow some increased level of functionality. Adding a DBMS to an existing 
AI system would also allow an increased level of functionality. 

Some research is already in progress on these alternatives. It is unclear how useful the 
stop gap measures will be. However, it is clear that the integration is useful, and since 
many systems are sorely lacking in certain areas, marginal improvements can have tre¬ 
mendous pay offs. Both fields must recognize that each has something to contribute to the 
other. 

EXPERT SYSTEM PROJECT SELECTION AND MANAGEMENT 

By Dr. George Humfeld 
Introduction 

Selecting your first expert system project and writing your first expert system proposal 
are intimately linked. When selecting your first expert system project, you must keep in 
mind how you are going to sell management or a customer on the idea. Similarly, the 
nature of the project effects the proposal. The unifying aspect of these two subjects, and 
an appropriate framework within which to discus them, is one of expectations: manage¬ 
ment’s (or customer’s) expectations, your expectations, the expert’s expectations, and the 
user’s expectations. 

Selecting a First Expert System Project 

When I first got involved in the AI field, I read books and magazines and attended 
symposia and conferences. There seems to be two ways in which to advise people on 
selection of their first expert system. 

One way is to describe the types of problems which are amenable to an expert system 
solution: interpretation, prediction, diagnosis, planning, design, repair, etc. This approach 
is taken by Frederick Hayes-Eoth, et. al., in the early chapters of Building Expert 
Systems. The problem with this approach is lack of specificity. Even if you select a 
problem which is obviously in one of the magic categories, that does not guarantee that an 
expert system solution is best, or even appropriate. 


AI-3 


AI-4 



A conventional software approach, or even a manual approach, may be less expensive, 
easier to develop, and faster running than an expert systems approach. It is important to 
keep these categories in mind as a lower level of abstraction of the idea of selecting a 
"knowledge intensive" problem, as opposed to a compute intensive problem. 

A second approach to advising one on selection of an expert system problem is to give 
maxims or rules-of-thumb which can be applied to the selection process. Figure 1 is a list 
of such maxims which I have compiled from a variety of sources. The problem with this 
approach is that some of these maxims contradict others, some won’t apply to particular 
problems, some (I suspect) aren’t useful under any conditions, and some are useful only if 
you already have broad experience building expert systems. These distinctions are almost 
never brought to light by the speakers or writers. The result is confusion on the part of 
those of us who are trying to select our first expert system project. I hope to shed some 
light on these maxims. 

Figure 1: Expert System Maxims and Requirements 
o High Pay-back Problem 
o Available and Willing Expert 
o Expert can Articulate Methods Used 
o High Management Visibility 
o Failed to Model Using Other Methods 
o Solution Requires Expertise 
o Complex Problem Which is Too Simple 
o Problem with Easy and Hard Versions 
o Expert can Solve in Several Minutes to a Few Hours 
o Expertise Scarce 
o Expertise Soon to Leave or Retire 
o Not Beyond Current AI State-of-Art 
o Experts’ Solution Consistent 
o Input Data Readily Available 
o Task Repetitive or Boring 
o Hostile Environment (Hazardous to Humans) 


o Solution Procedure can be Taught (1 Year Rule) 
o Solution Does NOT Require Common Sense Reasoning 
o Telephone Test 
o Fast Response Time Required 

o Operation of Expert System can be Evaluated by Experts 

Management Considerations 

First let us consider six of the above maxims in the light of management’s expectations. 
As you select your first expert system project, you might want to keep some of these in 
mind in relation to how your management or customer will view your project and how you 
are going to sell the idea to them. (Hereafter I will refer only to management, mostly due 
to my particular orientation. Most of these comments will apply equally well if you are 
dealing with a customer, as long as you bear in mind that we are talking here about the 
person, or group of persons, with approval, and possibly funding, authority over the pro¬ 
ject.) 

High Pay-back Problem 

This is always number one on everybody’s list. Texas Instruments has broadcast three 
satellite symposia on AI. In the first two Dr. Edward A. Feigenbaum of Stanford 
University referred to these problems as golden nuggets. These are the problems whose 
solution will save the company lots of money. Normally, these are large, complex prob¬ 
lems. Many have defied other types of solutions. But this is not necessarily the type of 
problem you want to tackle for your first expert system problem. 

An alternate approach proposed in TI’s second satellite symposium is to look for many 
"small-payoff" projects. I think this is a more appropriate attitude to take for your first 
expert system project. And it is being done in industry. In that same satellite symposium 
Dr. Ed Mahler of Dupont discussed a wide variety of small knowledge-based systems in 
operation or under development at Dupont. By 1990 they plan to have 2000 such systems 
in operation and a broad base of personnel trained in their development. 

In TI’s third satellite symposium Dr. Herbert Schorr of IBM indicated that his company 
currently has 75 expert systems in operation. It is clear from the way he talks about these 
applications that IBM is following this small system approach. He said that a project 
which pays back $200,000 in the first year could be worth doing based on payback- 
investment ratio if it took only two or three man-months and inexpensive tools. It is 
interesting to note that IBM seems to be using third party software on PC’s rather than 
their own tools on the mainframes. 

The advantages of going for what a friend of mine calls silver bullets, rather than the 
golden nuggets, are almost obvious: Initial investment is small. Successful applications are 
usable in short timeframe. Successful applications might be expandable into successful 
golden nugget applications of which they are a part. 
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High Management Visibility 

The choice of a problem with high management visibility may be important when you need 
lots of money. Here we are back to the golden nuggets. It is important that your project 
not get visibility too high in management too soon. Rather, get first-level, maybe second- 
level, management support early. Then elevate the visibility of the project as success 
becomes more assured. Wait until your prototype is useful in its existant form. Then 
elevate visibility as you expand its coverage and usefulness. 

Sometimes management visibility can be created as needed. This is particularly the case 
when expertise is scarce or expected to leave or retire soon. 

Expertise Scarce 

The engineers in my office spend a lot of time on the telephone giving advice to site 
personnel who are trying to troubleshoot equipment and procedure problems. We hope to 
distribute this relatively scarce expertise to the sites in the form of expert systems. 

I heard one speaker say to try not to choose a problem where the expert is in the 45 to 55 
year age range. People less than 45 generally don’t feel threatened because they are 
confident of finding another job, even if it means learning a new skill. Those more that 55 
are close enough to retirement not to worry and are interested in helping the organization. 

Expertise Soon to Leave or Retire 

Our site personnel are military and are typically on two to three year rotation. Needless to 
say, incoming personnel normally do not have the same level of technical knowledge as the 
outgoing personnel. Outgoing personnel often have knowledge about peculiarities regard¬ 
ing particular equipment they have seen on a regular basis during their tour. A dual 
coverage training period cannot always be arranged. 

Although the headquarters engineers generally stick around a little longer, the situation is 
almost the same. Management is quite concerned that corporate knowledge and expertise 
is leaving with each engineer who leaves the organization. Knowledge based programming 
in the form of expert systems can provide a way to capture and retain that corporate 
knowledge and expertise. These arguments can be used to create and elevate management 
visibility. 

Failed to Model Using Other Methods 

There are problems which are so important that conventional programming techniques 
have been applied to them with no real success. In some cases an expert system approach 
is just what is needed. In other cases, it’s not. So be very careful in tackling such a 
problem. You may not want to take on such a problem for your first expert system project. 
These problems often have high management visibility from the start. Failure could effect 
management impression of expert system technology in general. 

Task Repetitive or Boring 

This may seem out of place in a listing of management considerations. Naturally you can 
get better cooperation from your expert if you convince him that is will remove some of 
the repetitive and boring part of his or her job. I place this consideration here for two 
reasons. First, it seems to stand in direct contrast to the first two considerations. It is 
hard to believe that a repetitive or boring task is a high pay-back problem with high 


management visibility. Second, there is a direct relationship between such tasks and 
expert productivity. I’d like to use expert systems to dramatically cut the time our engi¬ 
neers spend on repetitive and boring tasks, leaving them freer to tackle real engineering 
problems. Doing so could favorably effect worker job satisfaction and turnover rate. 

Your Expectations 

The relationship of the following considerations to your expectations is discussed later in 
this paper. 

Not Beyond Current Al State-of-Art 

For your first expert system project you do not want to take on a research project. Choose 
a problem with a high probability for success. Some typical areas to be aware of include 
natural language understanding, machine learning, and computer explanation. 

In general, natural language understanding exists only for narrow applications and is not 
integrated into expert system shells. This is a great research area. Even natural language 
front ends for data bases are restricted to an understanding of how to deal with data base 
queries and have no understanding of the technical content of the data itself. 

Machine learning is used in two different ways. I’m not talking here about intelligent 
computer-based instruction. Rather I’m talking about your expert system learning by its 
own experience. Although some research is being done in this area, you should avoid it in 
your first expert system. 

Finally, watch out for the hype. I’ve yet to see an expert system shell with a really good 
explanation facility. Some will trace back through the rules which led to the final conclu¬ 
sion. But that is not the kind of explanation you would get from the expert. So, it leaves 
a lot to be desired. Some will allow you to preposition text files containing the desired 
explanation and will print out the appropriate file when requested. Sounds like a lot of 
work to me. This is ultimately a depth-of-knowledge problem. 

Solution Does NOT Require Common Sense Reasoning 

One of the big research projects of the MCC (considered by many to be the US answer to 
the Japanese Fifth Generation Project) is construction of an extremely large expert 
system incorporating common sense reasoning and analogical reasoning. This is a ten to 
fifteen year project. You don’t want to take on common sense reasoning in your first 
expert system. 

What is common sense? I’m hardly one to ask since my dad always said that I didn’t have 
any. But I’d say that common sense reasoning includes those chunks of information and 
reasoning methods which your expert doesn’t tell your about because "everyone knows 
that". As such, it is hard to recognize when your prospective problem requires it. So, this 
maxim may not have broad applicability. But if even you can see that solution of the 
problem will require a lot of common sense, take this as a warning and choose a different 
problem. 
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Complex Problem Which is Too Simple 

Talk about contradictions! This is actually two separate maxims. And yes, I got them both 
from the same source. Probably the best way to apply this maxim is to apply the next one 
in stead. 

Problem with Easy and Hard Versions 

If you can find such a problem, attack the easy version first. With that success under your 
belt, you have a useful prototype which you can use to convince management to give you 
the money and the expert to give you the time to expand toward a solution of the hard 
version. 

Hostile Environment (Hazardous to Humans) 

This is a very exclusive condition and will probably not apply to your case. You want to 
think about this if you are considering what jobs to give an autonomous robot in a 
radioactive or chemically contaminated environment. 

Considerations about Experts 

The following considerations relate to the expectations of the expert you will be working 
with in building your first expert system. 

Solution Requires Expertise 

If the problem does not require expertise to solve, then where are you going to find an 
expert? On the other hand, "expert" can be a relative term. Even a task which is accom¬ 
plished by many people within the industry might be a good candidate for expert system 
development if you need to distribute the capability more broadly than you would other¬ 
wise be able or to lower skilled people. Or you may use an expert system as a way to create 
and maintain consistency among experts. Repetitive, boring, and hazardous tasks are also 
good candidates even if the tasks involved require only minimal expertise. 

Available and Willing Expert 

If an expert is available, you might be able to motivate her or him to be willing to 
participate in the expert system building project. Consider how the expert system will help 
the expert— or the user if the expert wants to help others. Perhaps the expert could be 
interested in the project on the basis of investigation of new technology. For your first 
expert system you might consider using yourself as the expert. What are you expert at? 
Many companies are teaching their experts to use an expert system shell, letting the 
experts build the expert systems, and using the computer personnel (knowledge engineers) 
in an advisory capacity. 

Expert can Articulate Methods Used 

Don’t build your hopes too high in this area. Few experts are outstanding teachers and 
communicators. On the other hand, stay away from one who seems to enjoy "showing off" 
or one who never seems to realize when his or her audience is completely lost. Otherwise, 
this is not a consideration. 


Experts’ Solution Consistent 

This maxim relates to the case in which you are combining the expertise of several 
experts. If the experts will frequently arrive at different conclusions when looking at the 
same situation, or different solutions to similar problems, and if no single expert has 
generally acknowledged precedence over all others, you’re asking for trouble in your 
development effort. This is certainly nothing you want to get involved in on your first 
expert system development effort. 

Fast Response Time Required 

The overused buzzword "real-time" means different things in different situations. In most 
cases solutions are not required faster than a human can normally provide them. So, you 
can probably ignore this maxim or place it very low on the priority list when choosing an 
expert system problem. In fact, avoid choosing a problem for your first expert system 
project if response time is going to be a prime consideration in evaluation of the project. 

End User Considerations 

In selecting your first expert system project there are things which you should keep in 
mind about the effects on the potential users of the final product. Usually we focus too 
much on the expert and not enough on the users. 

Expert can Solve in Several Minutes to a Few Hours 

This is a measure of the boundedness of the problem. I’ve also seen this expressed as 
"Solution in 500 to 5000 rules" (totally useless if you’ve never written an expert system 
before, of marginal usefulness if you have), or "It typically takes the expert 15 to 150 
minutes to solve", or "The problem is bounded in numbers of procedures, outcomes, 
objects, relationships, and attributes". The idea is: If the problem is too simple, expert 
system technology is too expensive; use conventional technology. If the problem is too 
complex, an expert system solution is probably doomed to failure. And this is exactly the 
idea you should keep in mind. Don’t get too fixed on a number like 150 minutes. Rather 
use this maxim as a warning flag that you are reaching too far. 

Solution Procedure can be Taught (1 Year Rule) 

This maxim has some controversy surrounding it. Some feel that if it can be taught too 
readily, it is not an expert task. That is where the reference to the 1-year rule comes in. 
Ask the expert if someone could become reasonably competent at the journeyman level 
(not an expert) within a year. If so, this maxim is satisfied. This should satisfy most of 
those who insist that an expert system must emulate the reasoning process of a true 
expert. There are lots of processes which don’t require a scarce expert to solve and which 
would make fine problems for application of "knowledge based" techniques. 

Telephone Test 

The test is basically: Can the expert (or does the expert) instruct a reasonably technical 
person over the telephone in how to solve the problem for a particular situation. The prime 
application is trouble- shooting equipment failures. In fact, the engineers in my office do 
this frequently. It may not be a test you could use in other types of problems. I read about 
one expert system team using a screen between the interviewer and the expert (to simu¬ 
late telephone conversation) as a method of knowledge acquisition. 
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Input Data Readily Available 

Of course, you’d like to have all input data readily available for any type of computer 
solution. Very often you won’t know until you are well into the knowledge acquisition 
process that some forms of data (more exactly, information) are not readily available. In 
fact, in my office we expect the expert system development process to help us identify 
data availability deficiencies. The best bet here is to look critically at your potential 
problem. If it is clear that data availability is a major problem, reject the problem. A 
failure to solve the data availability problems may be interpreted as failure of the expert 
system technology. 

Operation of Expert System can be Easily Evaluated by Experts 

This is not a consideration. Usually you will not be able to determine if the operation of the 
expert system will be easily evaluated by the experts until your first prototype is ready for 
review. Even then the problem is more likely to be a user interface problem than a bad 
choice of problem. 

First Expert System Proposal 

We turn now to the problem of selling the idea of expert system development to manage¬ 
ment (or a customer). Different situations warrant different approaches to this problem. 
Different organizations require different paperwork and different levels of management 
review and approval. I can’t cover in half an hour a subject which is appropriate for a one 
or two day seminar. But I will suggest things you should take into consideration whether 
you are writing a proposal for your own management or for a customer. 

What Is The Political Climate? 

The first consideration is a political question which is seldom touched on by those who tell 
us what characteristics our expert system problems should have. Suppose your boss comes 
up to you and says, "It’s time we advanced to the forefront of technology. Expert systems 
is the best thing since sliced bread and we’ve got to have it! Drop everything! Go wher¬ 
ever, whenever you need to and find out what AI is! Get that first expert system started! 
And, by the way. I’m working on the paperwork for the promotion you’ve always wanted 
and never asked for!!!" 

Don’t you think you’d have a different perspective than if YOU first broached the topic, 
and your boss replied with "That stuff is pure poppycock! If it’s not written in FORTRAN 
(COBOL?), it’s not going to work! Don’t waste my time with this unproved, untested junk! 
Get back to work!!!" You’ve got to approach the problem differently in these two situ¬ 
ations. And, of course, the real world for you is, or will be, somewhere in between these 
extremes— and will require a different approach from either. The key is "What is your 
management’s expectations regarding expert systems technology?" 

As unrealistic as the preceding scenario may seem, it is really not far from the truth in 
many situations. In fact, that is very close to the situation I found myself in two years ago. 
As managers read glowing AI success stories in the technical pres, and feels a need to 
investigate expert systems technology, they tend to turn to their own staff. 


What Do You Want? 

Actually I lied. The political climate is the second consideration. The first is your personal 
objective in starting your first expert system project. Why do you want to do it in the first 
place? What do you hope to get out it? That is, what are your expectations? And how 
important are they to you? How flexible are you if your expectations have to be modified? 
If you will quit at the first signs that everything isn’t "going according to plan," then 
don’t even start. Why? Because you are getting started on something so new to you that 
your expectations are probably faulty. So keep an open mind and don’t overexpect, or 
oversell. You might want to refer back to the various factors discussed above relating to 
your own expectations. 

What Do They Want? 

In case you haven’t realized it yet, the first two considerations apply to any project you are 
likely to propose, not just your first expert systems project. This is true of the third 
consideration too. What corporate objectives can be addressed by building this expert 
system? What are the objectives of your management (organizational as well as personal)? 
Any project must be justified on the basis of the benefit which will accrue to the organiza¬ 
tion. In some cases it is sufficient to claim "exploration" or "evaluation" of new tech- 
nology which may have some long term value. But more often the justification has to be in 
terms of the "bottom line." 

You may think this sounds funny coming from someone who works for the Government, 
and DoD at that. But please believe me when I say that it is no less true in Government 
circles than in private industry. The motive is in terms of staying within budget or cutting 
budget, rather than profit. But the principle is the same. Relate what you want to do to: 
The Mission, The Charter, The Bottom Line, and even your supervisor’s personal objec¬ 
tives. And now the tightrope: In doing so, don’t create expectations on the part of manage¬ 
ment which there is a good chance you can’t meet. That is the best way to snatch failure 
from the jaws of victory and glory. 

Figure 2 lists some of the selling points you can use to convince management. Most of 
these relate back to considerations given above when deciding on a first project. Increased 
productivity can result from automation of repetitive, boring tasks. Increased consistency 
is important when several people perform the same task, such as when the resulting 
expert system is going to be used to distribute expertise currently held by one or a few 
experts. Preservation of expertise can be correlated to "corporate knowledge bases" which 
sometimes disappear with departing employees and to training of new personnel. When 
using the last item on the list, be very careful what you promise. Remember that I 
recommended against choosing a project like this for your first effort. In addition to 
arguments in Figure 2, a firm economic analysis can do wonders. 

Figure 2: Selling AI To Management 

o Increased Productivity 

o Increased Consistency 
o Reduced Errors 
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o Preservation of Expertise 
o Distribution of Expertise 
o Solution of Formerly Intractable Problems 

Realize the Importance of Initial Success 

These first three principles are absent from almost everything I’ve ever read on this 
subject. The next two are always there. Make sure you have an expert at your disposal 
(and make sure she or he is interested in helping). Choose a problem which has some 
importance to the organization but is not terribly complex. Use expert and organizational 
importance to sell the project. Both are satisfied with relative ease in an organization of 
any size. The trick is getting them satisfied together: The interested expert has to have 
his expertise in the domain of the important problem. 

Who is the Expert? 

Does an expert exist? Can you interest her or him in the project? The involvement of the 
expert is so important that you might think about what you are expert at yourself. There 
is some trend toward teaching domain experts to use expert system tools and letting them 
develop their own applications. The computer professionals (knowledge engineers) become 
a resource to help the expert set up his solution, reformulate it when necessary, suggest 
alternative tools, provide information on complexities of the tool, and so forth. If you 
adopt this approach, consider carefully the tools you make available. Remember that the 
expert is a user of those tools, perhaps not a computer literate user. 

What is the Intended User Environment? 

Another aspect of choosing and selling of expert system problem too often ignored by 
authors is a consideration of the intended user environment. Actually, the few who do this 
are given titles containing the words "human factors" and invited to present their own 
papers. They seem to have their own corner at AAAI and the like, and their work is not 
integrated well with other AI research (personal opinion). Simply stated, management 
expectations will not be met if the project ends with an expert system which cannot be 
used by those who (in the eyes of the managers) need it most. In essence, you should have 
a workable delivery plan before submitting, or even hyping, the development effort. 

Note: Economics is often a prime consideration here. Purchase of a high-cost workstation 
for the one user in the organization may not be a workable plan. Why? Because if this 
thing catches on, the organization can’t get one for each engineer. Also, space and power 
constraints may have an impact. 

So, what is involved? Well it doesn’t necessarily mean that you absolutely have to restrict 
yourself to available computer resources. Check with those in the know, and find out what 
the corporate plans are. If you are in an organization with 35 engineers using a single PDP 
11/70 and 15 terminals, your company is probably ready to consider an upgrade. So, talk 
up the VAX line and individual workstations. In a micro-computer environment, talk up 
IBM PC compatible. These are the platforms of the present and. I believe, of the next 
decade for delivery. 


That is not to say that you cannot develop your expert system in one environment and 
deliver in another. But I think you would be wise to choose a development environment 
which is very close to (i.e., compatible with) the delivery environment. Once the 
"engineering" part of the project is over and you have a functional expert system on your 
special purpose LISP machine, try to convince your management that your need another 
three or four months and another $40K to convert to FORTRAN so it will run on the CDC 
mainframe your engineers use. (People seriously propose solutions of this kind!!) 

Be sure you know what the users’ needs are, even if the users don’t. Think about what will 
and what won’t meet these needs BEFORE writing your proposal. Use potential increase 
in user productivity and quality of users’ work in selling your project. 
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AUTOMATED REASONING TOOL NOW RUNS ON VAX/VMS SYSTEMS 

By Terry C. Shannon 

LOS ANGELES, Calif. - In a move that significantly broadens the market for commer¬ 
cial artificial intelligence applications. Inference Corporation has debuted ART/VMS, a 
C-based implementation of the firm’s ART (Automated Reasoning Tool) expert system 
development tool. The latest member of the ART version 3.0 family, ART/VMS brings to 
the conventional computing environment capabilities that previously required the use of a 
dedicated symbolic processor or "Lisp Machine." 

The ART/VMS announcement, while somewhat belated, heralds Inference Corp.’s entry 
into the computing mainstream, an arena which has become populated by expert system 
development products from a growing number of AI software vendors. 

ART is a knowledge engineering language and development environment that provides 
rule-based, frame-based and procedure-based knowledge representation paradigms. Among 
the tool’s features are forward and backward chaining control schemes, certainty handling 
mechanisms and a knowledge base structure that permits AI developers to generate hypo¬ 
thetical worlds by defining the contexts in which rules and facts apply. 
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ARTs’ ability to concurrently generate and test multiple hypotheses is based on a unique 
"viewpoint" mechanism. In ART, a viewpoint is a frame of reference through which the 
tool views the facts in a knowledge base. Each time a viewpoint is created, ART’s rules 
may view only those facts that have been created for, or inherited by, that viewpoint. 

Through the use of viewpoints, ART can reason in parallel about various partial solutions 
to a problem. This strategy permits the tool to simultaneously evaluate rules that repre¬ 
sent multiple courses of action, thereby improving its efficiency. Less sophisticated knowl¬ 
edge engineering tools, by contrast, must commit to one possible solution until it is proved 
wrong, then backtrack to a decision point and restart the process of selecting and applying 
rules in a new decision path. 

The ART/VMS implementation includes four ART version 3.0 enhancements that boost 
the tool’s performance and efficiency. Chief among these is an improved memory manage¬ 
ment technique that automatically allocates and deallocates memory to eliminate so-called 
garbage collection or memory recycling. A new pattern-matching structure called a 
"generalized join topology" lets ART join rules in its data base from the left, as in other 
rule-based tools, and also from the right. The improved pattern-matching technique speeds 
the process of comparing complex patterns within ART knowledge bases, reducing system 
overhead and application run-time. 

ART’s object-oriented programming capabilities have been strengthened by a procedural 
attachment feature that lets developers define specific functions for classes of objects. A 
new "multi-methods" technique lets groups of objects act in unison, reducing the amount 
and complexity of code in typical ART applications. According to Inference Corp., ART is 
the first commercial expert system development tool to implement multi-methods. 

The execution speed and security of ART applications is also enhanced by a binary file 
storage feature that lets developers compile and store ART rules in binary format. In 
addition to loading up to 10 times faster than source code files, binary files make it 
possible for developers to deliver customer applications in a format that protects pro¬ 
prietary source code. 

ART/VMS also includes two powerful interactive graphics facilities that make the tool 
more accessible to novice AI developers and end users. The ART Studio helps AI devel¬ 
opers construct knowledge systems as well as monitor their execution at run-time. The 
complementary ARTIST facility lets developers define interactive user interfaces for 
knowledge systems. For example, a valve or switch created with ARTIST could be interac¬ 
tively manipulated by the user to change a value in the ART knowledge base. 

For more information about ART/VMS, contact Inference Corp., 5300 W. Century Blvd., 
Los Angeles, CA 90045 (213) 417-7997. 

FRAME-BASED PC EXPERT SYSTEM DEVELOPMENT TOOL DEBUTS 

By Terry C. Shannon 

Underscoring the value of the microcomputer as an AI application development and de¬ 
livery platform. Expert Systems International, a Philadelphia, PA AI software vendor, 
recently announced an extensible, frame-based software tool for building expert systems. 
Called the ESP Frame-Engine, the new AI development tool runs on the IBM PC. PC/XT, 
PC/AT and compatible microcomputers such as the DEC VAXmate. 


The ESP Frame-Engine consists of several individual components. A collection of frames 
and rules, or knowledge base, defines the system’s knowledge about a specific topic in the 
terms of a Knowledge Representation Language (KRL). After being created and edited 
with a word processor, the KRL code is scanned for errors and translated into an internal 
format by the KRL compiler. Next, the inference engine, or rule interpreter, makes infer¬ 
ences from known to unknown information using the frames and rules in the knowledge 
base. 

The Frame-Engine and the application developer communicate with each other through a 
window-based knowledge engineer’s interface. Finally, a window-based client interface 
communicates with the end user by asking questions and explaining why the questions are 
being asked. The client interface also displays advice and conclusions and checks the 
validity of user responses. 

According to Expert Systems International president Angelos T. Kolokouris, the ESP 
Frame-Engine’s frame-based architecture supports rule and variable groupings as well as 
inheritance. In addition, the tool lets AI developers write object-oriented programs with 
numeric, boolean, text, set and instance objects. 

The tool also provides set operations and an integrated reasoning mechanism that sup¬ 
ports both forward and backward chaining, making it compatible with predictive and 
diagnostic knowledge system applications. Written in Expert Systems International’s 
Prolog-2, the ESP Frame-Engine features an open architecture that lets programmers 
interface the tool with applications and routines written in PROLOG-2, C and other 
conventional programming languages. 

Designed for customized applications and enhancements by the end user, the ESP Frame- 
Engine includes an I/O module that can be modified to conform with existing programs 
and software packages, making the tool appropriate as an expert system development 
facility or as an integral component of existing software applications. "For example," 
Kolokouris said, "a developer can modify the I/O module to access external disk-resident 
databases or invoke external code routines from within a Frame-Engine application." 

The use of a frame-based knowledge representation strategy, a technique pioneered by AI 
researcher Marvin Minsky, lets AI developers efficiently organize and structure informa¬ 
tion about the attributes, characteristics, features and properties of an object or event. 
"The nearest equivalent to a frame in a language such as Cobol or Pascal is the record or 
structure. These constructs, however, lack the defaults, inheritance capabilities and rules 
which are implemented in frames," Kolokouris said. 

According to Kololouris. the ESP Frame-Engine is designed to meet the needs of a wide 
variety of AI developers. "Expert system shell users who want to move onto something 
more ambitious but who are not inclined to use an AI language such as Prolog will be 
among the primary beneficiaries of the Frame-Engine," he said. "Likewise, experienced 
knowledge engineers should find that [the tool] permits rapid prototyping of AI applica¬ 
tions. " 

"Because the ESP Frame-Engine is an expert system language, it provides more power 
than a typical rule-based PC expert system shell. In addition, the product’s Knowledge 
Representation Language provides the flexibility of a programming language such as 
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Prolog, together with the expressiveness of a frame-based knowledge formalism/' 
Kolokouris observed. 

The ESP Frame-Engine is distributed on two MS-DOS floppy diskettes and accompanied 
by a comprehensive reference manual and user’s guide. Commercial and academic licenses 
are available from Expert Systems International, 1700 Walnut Street, Philadelphia, PA 
19103 (215) 735-8510. 

LISP TOOLKIT SPEEDS VAX-BASED Al APPLICATION DEVELOPMENT 

By Terry C. Shannon 

Claiming to shorten the VAX-based AI application development and delivery cycle. 
Artificial Intelligence Technologies (AIT) has begun shipping Release 1.2 of the AIT Lisp 
Toolkit. 

AIT director of sales and marketing Richard E. Muccini says that the latest release of the 
AIT Lisp Toolkit features increased efficiency and a variety of new features that help VAX 
Lisp and Inference Corp.’s Automated Reasoning Tool (ART) developers integrate VAX 
Lisp applications with DEC layered software products including Rdb, CMS/MMS, FMS, 
GKS and DECnet. In addition, the Toolkit lets VAX Lisp programs communicate with 
applications written in conventional languages such as C, Cobol, Fortran and Pascal. 

"The ability to access DEC’s layered products from VAX Lisp has proven very valuable to 
expert system developers using VAX Lisp." Muccini said, adding that VAX Lisp-based AI 
applications frequently need to integrate the knowledge portion of the application with 
other VAX-resident systems software tools such as relational databases, graphics, net¬ 
working and conventional programming languages. 

According to Muccini, the latest release of the AIT Lisp Toolkit features an enhanced Rdb 
module that is fully compatible with Rdb version 2.2. "The VAX/Rdb interface lets the 
VAX Lisp programmer use relational database technology to build large knowledge and 
data bases. By keeping data in Rdb and calling it into memory only when needed, the 
programmer frees up virtual address space for more productive uses," Muccini said. 

The enhanced Rdb module supports cacheing of expanded macros to increase the execu¬ 
tion speed of interpreted Lisp code, the use of arbitrary Lisp code during record selection 
and automatic database invocation to ensure successful data retrieval. 

The Toolkit’s Graphical Kernel System (GKS) module has been enhanced to provide sev¬ 
eral new VAXstation II/GPX features, including GPX/2b support, full output support 
including segment creation and manipulation, support for multiple workstations and 
workstation-independent segment storage. "The VAX/GKS module can greatly increase 
the effectiveness of an expert system’s user interface by display information in graphical 
form," noted Muccini. 

Similarly, the Forms Management System interface allows for quick development of video- 
based forms which are similar in appearance to everyday paper forms. According to AIT, 
the graphical interface lets the AI developer quickly and easily provide an unintimidating, 
self-explanatory delivery environment for the end user." 


The AIT Lisp Toolkit also provides a natural language processing facility, an enhanced 
Lisp top level, a Lisp editor window facility and an interprocess communication capability 
that can be used to develop distributed, cooperative Lisp-based expert systems. "With the 
AIT Lisp Toolkit’s development facilities, developers can use a wide variety of tools that 
save time and money while providing more flexible, higher performance AI systems that 
are easy to maintain," said Muccini. "For example," he added, "the Toolkit lets DEC 
VT240 and VT241 terminals emulate more powerful workstations and fully utilize the 
Toolkit’s windowing facility to display data more efficiently." 

The Toolkit’s Lisp-based natural language processing facility helps VAX Lisp program¬ 
mers develop and deliver user-friendly AI applications. "Ultimately, the success of any 
application is its ability to provide solutions to complex problems while offering a user- 
friendly environment that gets results," Muccini noted. "When used as a front end to the 
knowledge base or data base, the Toolkit’s Natural Language Processor lets end users get 
information from expert systems without any knowledge of Lisp or AI programming 
techniques. This reduces the need for the developer to be on call every time an end user 
needs a special report," he added. 

According to Muccini, the AIT Lisp Toolkit is a minimal garbage implementation that 
reduces the possibility of sudden system interruptions that occur when an AI program 
must pause to perform "garbage collection." or the recycling of virtual memory. "This 
feature provides substantial benefits to VAX AI application developers and end users alike. 
For example, the Toolkit makes it possible for Lisp programmers to develop and deliver 
applications requiring high availability," Muccini said. 

The AIT Lisp Toolkit is now in use by AI application developers in the aerospace, publish¬ 
ing, process control and energy industries. For further information about the AIT Lisp 
Toolkit as well as AIT’s customer support facilities and consulting services, contact 
Artificial Intelligence Technologies, Inc., 1 Skyline Drive, Hawthorne, NY 10532 (914) 
347-6860. 

SECOND-GENERATION CONNECTION MACHINE UNVEILED 

By Terry C. Shannon 

DEC VAX and Symbolics Lisp machine users whose data-intensive applications require 
supercomputing power will soon be able to draw upon the resources of an enhanced 
Connection Machine from Thinking Machines Corp. 

A successor to the firm’s original 1000-MIPS Connection Machine, the CM-2 is a 
massively parallel processor equipped with 65,536 one-bit microprocessors and 512 MB of 
physical memory. The CM-2 provides an I/O bandwidth of 75 to 300 gigabits per second, 
a substantial improvement over its predecessor. 

According to the vendor, the CM-2 will be available with 32-bit single-precision and 64-bit 
double-precision floating point options that enable the parallel processor to achieve peak 
speeds of 2500 to 3500 Mflops for applications such as molecular modeling, signal process¬ 
ing and seismic research. 

Users with less intensive supercomputing requirements will be able to purchase a scaled- 
down CM-2 system that employs 16,384 microprocessors and 128 MB of physical memory. 
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The CM-2 can be front-ended by a Symbolics 3600 processor or a VAXBI-based VAX 8000 
system. At a cost of from $1 million to $6 million dollars, the CM-2 is perhaps the most 
expensive VAXBI-compatible "peripheral" supported by the VAX family. 

Thinking Machines also debuted DataVault, a fault-tolerant mass storage system employ¬ 
ing multiple hard disks. Similar in concept to a forthcoming array of Digital disk drives, 
the DataVault system will be available in 42 and 84-spindle versions that store five and 10 
GB of data respectively. 

The CM-2 can also be equipped with a new high performance graphics display system as 
well as C, Lisp and Fortran compilers. Thinking Machines will begin shipping the CM-2. 
the single-precision floating point processor option, mass storage system, display system 
and C and Lisp compilers during the third quarter of 1987. The double-precision floating 
point processor option and Fortran compiler are expected to be available in early 1988, a 
company spokesperson said. 

VAX CDD-COMPATIBLE EXPERT SYSTEM SHELL DEBUTS 

By Terry C. Shannon 

Level Five Research, Inc., an AI software vendor in Indiatlantic, FL, recently debuted 
PRL3, an easy-to-use, rule-based expert system development and delivery tool that ex¬ 
ploits the data management features of DEC’S VAX superminicomputer family. 

An upwardly compatible successor to Level Five’s family of PC-based expert systems 
tools, PRL3 combines hardware transportability and accessibility to external software and 
databases with the power and connectivity of VAX systems. In addition to eliminating the 
need for dedicated processors or graphics workstations, PRL3 is substantially less expen¬ 
sive than other high-end expert system development tools. 

According to Level Five marketing manager Cornelius Willis, the multiuser and network¬ 
ing capabilities of the VAX permit the simultaneous use of a PRL3 expert system by an 
entire organization. Moreover, all knowledge bases developed with PRL3 on a VAX system 
can be shared by ail users. 

PRL3 uses Level Five’s proprietary Production Rule Language (PRL), a knowledge repre¬ 
sentation strategy that states rules and facts in English-like "IF-THEN" constructs. 
Because the Production Rule Language is common to Level Five’s entire line of expert 
system tools, any knowledge base developed with a Level Five PC-based expert system 
shell can be used on a VAX system with PRL3. 

Level Five president Henry Seiler explained that PRL3 is an anomaly in the world of 
expert systems tools. "AI has always been a solution that was out of touch with the needs 
of its users. In contrast, our corporate customers were intimately involved with the 
requirements specification and design phase of the PRL3 project," Seiler said. 

One of the most notable participants was E.I. DuPont, which purchased an unlimited 
world wide license for the tool prior to its release. Du Pont is well known for the phenome¬ 
nal success of its "AI Task Force" headed by Dr. Ed Mahler. Du Pont has fielded several 
hundred real-world expert systems based on Level Five AI tools. 


"Du Pont’s involvement in the design of PRL3 was extremely helpful to us," said Seiler. 
"It helped us focus on issues that are critical to real world expert systems applications, 
rather than ’AI esoterica’." 

Because few commercially successful expert systems run as standalone applications, PRL3 
directly integrates database access with its rule and context management system. Popular 
VAX databases, including the VAX Common Data Dictionary (CDD), DATATRIEVE, 
Rdb/VMS, DBMS, and BBN Software’s RS/1 database management package can be easily 
accessed from within PRL3. The tool also provides access to any VAX RMS file through 
the CDD and is fully integrated with the EDT editor. 

PRL3 contains both an object library and a linkable library of utilities. With the object 
library, users can build and access custom databases with PRL3’s database grammar. The 
linkable library facility manages communications between the expert system and any 
user-written application. 

PRL3 is available as a full expert system development environment or as a run-time 
application delivery system. Optional interface modules are available for the DEC CDD 
and BBN Software’s RS/1 database system. 

IBI FOCUSES ON AI TECHNOLOGY 

By Terry C. Shannon 

NEW YORK, NY— Fourth generation language and database management system 
vendor Information Builders Inc. (IBI) is poised to bring AI technology into sharp focus 
with the acquisition of Level Five Research, a Melbourne, FL, AI software vendor whose 
products include the VAX-based PRL3 expert system shell. 

In a letter of intent signed earlier this month, IBI disclosed its plans to bring knowledge- 
based capabilities to the FOCUS environment by purchasing Level Five Research and 
integrating the firm’s AI technology into the IBI software family. 

Cohen explained that IBI and Level Five address similar data management issues, making 
the forthcoming merger a mutually beneficial agreement. "Both [IBI and Level Five 
Research] provide powerful application development tools that are easy to use, and to¬ 
gether will offer interfaces to reach data no matter where it resides," he said. 

Level Five Research president Henry Seiler said that end users will benefit from the 
IB I/Level Five alliance because it foreshadows improved connectivity between expert 
system shells and the knowledge that they manipulate. "The trend in the expert systems 
marketplace is towards the merger of expert system technology and productivity tools," 
Seiler said. 

"We feel that small expert system tool vendors are spending too much time and effort 
developing database interfaces. By teaming up with IBI. we can concentrate on comple¬ 
menting IBI’s database access and productivity features with AI technology instead of 
reinventing the 4GL wheel." 
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Commenting on future product directions, IBI’s Cohen said that Level Five’s VAX and PC 
expert system tools, PRL3 and Insight 2+ will be marketed by IBI in the immediate 
future. "We are planning to port Level Five products to run on IBM mainframe computers 
as soon as possible," he added. 

The next step, according to Cohen, involves the development of interfaces which will allow 
Level Five AI tools to access FOCUS databases. Ultimately, the firms will integrate 
rule-based knowledge systems into FOCUS to create a comprehensive decision support 
and application development system that provides the best features of both products. In 
addition, Seiler noted that the firms plan to release Macintosh and UNIX versions of 
Level Five’s AI software. 

The IBI/Level Five alliance is similar in concept to Cullinet Software’s recent acquisition 
of Distribution Management Systems, a software developer specializing in expert system 
software that runs on VAXes and IBM mainframes. 

Like Cullinet and Distribution Management Systems, IBI and Level Five Research can 
capitalize on visibility and market penetration. With more than 5,000 software packages 
installed since the firm was founded in 1984, Level Five Research claims to have the 
largest customer base in the expert systems industry. Similarly, IBI says that its FOCUS 
product is the most widely installed 4GL/DBMS for application development and end-user 
computing on mainframes, superminis and personal computers. 

A SILVER LINING IN SYMBOLICS’ CLOUD? 

By Terry C. Shannon 

Beleaguered by its image as a purveyor of special purpose computers that are regarded by 
a growing number of computer users as overpriced, anachronistic "islands of automation," 
Symbolics Inc. has thrown down the gauntlet with its new Ivory Lisp microprocessor chip 
and a new corporate strategy that will emphasize alliance instead of isolation. 

According to corporate representatives. Symbolics, the premier vendor of symbolic proces¬ 
sors used in artificial intelligence research and development applications, will use its 
recently unveiled Lisp chip as a gateway into the conventional computing arena. 

Although commercial data processing applications and Lisp machines have long been 
mutually exclusive. Symbolics vice president of marketing Ilene Lang contends that the 
price and performance of the Ivory Lisp CPU and its successors will have a significant 
impact on the commercialization of artificial intelligence, expert systems and related 
symbolic processing applications. 

"The market for symbolic processors has been largely technology-driven, with newer hard¬ 
ware and software technologies stimulating innovation in new industries and areas of use. 
The advent of [the Ivory] chip technology, however, changes the emphasis to a more 
mature, application-driven market," Lang said. 

Lang explained that advances in machine architecture, knowledge representation and 
symbolic programming languages will continue to drive the upper limits of artificial intel¬ 
ligence research and development— the application area that has traditionally been 
Symbolics’ primary market niche. 


At the lower end, however, Lang predicted that price and performance breakthroughs such 
as those embodied in the Ivory chip will recast symbolic processing technology as a de 
facto component of the traditional computing environment. "The result will be greater 
availability [of AI technology] to mainstream users and a proliferation of products in 
mainstream application areas." she said. 

One prominent AI practitioner observed that Symbolics’ continued viability is contingent 
upon the firm’s penetration of the commercial computing environment. Noting that 
Symbolics processors have long dominated academic and government AI research labs, 
the practitioner indicated that the Lisp machine vendor must cultivate new markets to 
maintain its cash flow and internal research and development program. 

"The artificial intelligence research and development marketplace has become saturated. 
Symbolics must expand its horizons to compete with mainstream vendors who now offer 
symbolic processing languages on their conventional hardware offerings." he concluded. 

Although more than 3,500 Symbolics Lisp machines are in use at some 500 customer sites 
worldwide, the prime beneficiaries of Symbolics’ effort to make artificial intelligence an 
integral component of conventional computing have been traditional hardware vendors and 
AI language and tool developers whose products run on conventional computer systems. 

For example, DEC VAXes and IBM mainframe systems support symbolic programming 
languages such as Lisp, Prolog and OPS5. and vendors of high-end expert system shells 
are porting their products from dedicated symbolic processors to conventional computers 
and workstations. 

Additional competitive pressures are being exerted on Symbolics by PC AI software devel¬ 
opers. Exsys, Inc. of Alburquerque, NM: Level 5 Research, Inc. of Indiatlantic, FL and 
Neuron Data of Palo Alto. CA, are among the vendors who have fielded VAX/VMS ver¬ 
sions of their PC expert system tools within the past six months. 

Symbolics has responded to the inroads made by conventional computer manufacturers 
and software vendors by embracing industry standard networking protocols and program¬ 
ming languages while readying a next-generation family of high-performance, low-cost, 
multiprocessor-based symbolic computers based on Ivory technology. 

THREE-PRONGED ATTACK 

In addition to continuing its support for industry standards and developing a series of 
hybrid processors. Symbolics will base its mainstream computing foray on marketing 
agreements with as-yet-unspecified third party vendors who want to incorporate Lisp 
coprocessors into their conventional computer hardware. 

According to Symbolics, the Ivory chip’s 40-bit word length accommodates full 32-bit 
addressing and integer lengths. Symbolics VLSI design group director Neil Weste pointed 
out that Ivory’s 32-bit addressing ensures machine-level compatibility with general pur¬ 
pose computers. "This means Ivory can process 32-bit data, which will be very important 
to anyone who wants to build machines with industry-standard 32-bit processors." he said. 
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While Symbolics refused to discuss the status of negotiations with third party hardware 
vendors and potential OEMs, Lang said that the firm is excited about the Ivory announce¬ 
ment and its future ramifications. "We are supporting the 32-bit standard and [we are] 
talking with a number of third-party hardware vendors," she said. 

Don Brown, an analyst with D.H. Brown and Associates, a market research firm in 
Tarrytown, NY, observed that Ivory’s 32-bit compatibility makes the chip an attractive 
option for conventional computer vendors— such as Digital— who may want to comple¬ 
ment their existing hardware with a symbolic coprocessor. 

Brown contended that a Lisp coprocessor would give Digital easy access to symbolic 
computing capabilities without impacting the existing VAX product line. "It’s not clear 
that the VAX architecture is suited to fully capitalize on Lisp and symbolic processing," 
Brown said. 

Noting that the modification of the VAX instruction set would be a difficult decision that 
would affect all of Digital’s mainstream users and create software compatibility problems. 
Brown claimed that the inclusion of a coprocessor such as the Ivory chip would be a more 
viable strategy for enhancing the symbolic processing capabilities of the VAX family. 

SYMBOLICS UNVEILS NEW SOFTWARE 

By Terry C. Shannon 

As part of an ongoing effort to bring symbolic processing into the computing mainstream. 
Symbolics, Inc. has unveiled release 7.1 of Genera, a proprietary operating system and 
software toolkit that runs on the Symbolics 3600 processor family. 

Commonly referred to as "Lisp machines," Symbolics systems are high performance 
workstations whose architecture is optimized for the efficient execution of programs writ¬ 
ten in Lisp. These systems feature high-resolution graphics, a sophisticated user interface 
and a variety of program development tools that speed the development of AI applications 
as well as programs coded in conventional languages such as Ada, Fortran and Pascal. 

According to Symbolics Genera product manager Scott Garren, the latest release of the 
Genera software environment makes Symbolics processors even more appropriate for the 
development of traditional and knowledge-based software applications. 

Genera version 7.1 offers improved processor performance, multivendor network support 
and tools that simplify the conversion of Lisp machine-specific programs into code that is 
compatible with the Common Lisp standard. 

The new Genera release provides a variety of facilities for data management and large- 
scale program development. Chief among these are an improved user interface and win¬ 
dowing facility, enhanced disk performance and more efficient paging and "garbage collec¬ 
tion." Garbage collection is the technique through which a Lisp machine reclaims or 
recycles physical memory that becomes filled with obsolete data structures during the 
execution of Lisp programs. 


The Genera operating environment includes Symbolics Common Lisp, a standardized Lisp 
programming language implementation that provides built-in extensions for object- 
oriented programming. "Symbolics has always supported industry standards, and those 
standards— such as Common Lisp— are even more important now that the commercial 
market for symbolic processing is maturing," Garren said. 

Garren explained that the Genera environment includes a conversion aid that helps users 
convert Lisp machine-specific Zetalisp programs into Common Lisp to increase application 
portability. The new conversion aid consists of online documentation and separately load¬ 
able software that uses special-purpose editor commands to assist conversions of large 
blocks of code from Zetalisp to Common Lisp formats. 

After noting that over 90 percent of Symbolics’ installed base of 3,000 processors are used 
in heterogeneous computing environments. Garren said that' the latest Genera release 
provides enhancements to the Symbolics Generic Networking System’s DECnet and TCP/ 
IP facilities. Because the networking system also supports SNA, Ethernet and Symbolics 
networking protocols, Garren explained. Symbolics processors can be easily integrated 
into multinetwork, multivendor computing installations. 

The Generic Networking System includes a consistent command set that lets users 
transparently access files that reside on local or remote Symbolics processors, IBM main¬ 
frames, VAX/VMS systems and UNIX workstations. The software also features support 
for logical pathnames, electronic mail, an interactive communications facility similar to the 
VMS Phone utility and single-keystroke remote login and device access. 

Genera 7.1 software will be offered to all Symbolics customers as a replacement upgrade 
for Genera versions 6.1 and 7.0. The new release includes all applicable updates to 
Symbolics’ layered products including the Prolog, Ada, Fortran and Pascal programming 
languages as well as TCP/IP, DECnet and SNA networking protocols. 

MEETING PORTENDS COMMON LISP STANDARD 

At a meeting held during mid-March in Palo Alto, CA, the National Technical Committee 
for Standardization of Lisp (X3J13) began to lay the groundwork for an object-oriented 
Lisp programming system. According to the committee, "X3J13 is chartered to produce 
an American National Standard for Common Lisp. It will codify existing practice and 
provide additional features to facilitate portability of code among diverse implementa¬ 
tions. " 

Resolved in March by the National Technical Committee for Standardization of Lisp 
(X3J13) were the following: 

(1) The committee believes that object-oriented programming will be incorporated as part 
of a future Common Lisp standard; 

(2) The committee believes that Chapters 1 and 2 of the Common Lisp Object System 
(CLOS) specification (collectively, X3J13 document 87-002) captures the essentials of the 
future standard object facility. 
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AISIG PERSONAL COMPUTER WORKING GROUP INITIALIZED 

By Bob Woodward 


10-14 

Stanford Short Courses 


At the Nashville Symposium, a working group was formed in the AISIG to the use and 
exchange of information about personal computer based AI tools, particularily expert 
systems. The purpose of this group is to establish a network of communication among 
DECUS members doing work in this area and to encourage participation at future 
symposia. Ultimately, we would like to do the following: 

o Compile and distribute a list of people, tools and applications related to PC-based artifi¬ 
cial intelligence. This list would also include people who are interested but have no current 
applications. 


Code Optimization & Code Generation 
Joleen Barnhill 

Western Institute in Computer Science 
P.O. Box 1238 
Magalia, Ca. 95954 
(916) 873-0575 

10-15 


o Solicit and compile articles for (THE (LINKED LIST)) relating actual applications and 
product evaluations. 


Human Computer Interaction 
Honolulu, HI 


o Ensure that our interests are adequately represented at future DECUS symposia. What 
kind of symposia topics would be helpful to you? Would you be able to present a sympo¬ 
sium session relating to this area? 

To join this working group, write: 


17-20 

2nd Inti. Workshop on Natural Language Understanding and Logic 

Programming 

Vancouver, BC 


Robert Woodward 
Conoco Inc. 

OASIS 2018 
PO Box 2197 
Houston, TX 77252 

AI EVENT CALENDAR 

By Jim Sims, DECUS AISIG Steering Committee 
August 1987 


23-28 

IJCAI-87 10th International Joint Conference on Artificial 
Intelligence Milan, Italy 

Alan Bundy 

Dept, of Artificial Intelligence 
University of Edinburgh 
80 South Bridge 
Edinburgh, EH11HN, UK 


3-7 


24-26 


Stanford Short Courses 

Computer Graphics, Giving Programs Common Sense, Compiler 
Construction/ Programming Language Translation 
Joleen Barnhill 

Western Institute in Computer Science 
P.O. Box 1238 
Magalia, Ca. 95954 
(9161 873-0575 

4-7 

2nd International Conference of Applications of AI in 

Engineering 

Boston, MA 


International Workshop on Petri Nets 
Madison, WI 

31-Sept 3 

European Conference on AI in Medicine Marseilles, France 

Theory, Design, and Application of AI in Medical Systems 

Viviane Bernadac 
AIME 87 IIRIAM 
2 rue Henri Barbusse 13241 
Marseille Cedex 1 FRANCE 

September 1987 
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21-25 

European Congress on Simulation Conference and Exhibition 
Prague, Czechoslovakia 

ECS ’87 

do Director, Institute of Computer Sciences 
Czechoslovak Academy of Sciences 
182 07 Prague 
P.O. Box 5 

Czechoslovakia 846669 

October 1987 

5-7 

Spatial Reasoning and Multi-Sensor Fusion 
Pheasant Run Resort St Charles, Ill. 

Spatial Reasoning, Multiple Sensor Inputs, Spatial Planning, 

Formal Theory, Fusion of Sensory Inputs, Evidential Reasoning 

CFP to: Su-shing Chen 
Dept, of Computer Science 
University of North Carolina 
Charlotte, NC 28223 

5-7 

Workshop on Computer Architecture for Pattern Analysis and 
Machine Intelligence 
Seattle, WA 

5-7 

Workshop on Spatial Reasoning and Multi-Sensor Fusion 
St. Charles, IL 

Topics to include: Reasoning about shapes from partial evidence, fusion of photometric and 
range data for mobile robots, fusion of 2D, 3D. tactile, and FIT sensing for assembly 
robots, evidential reasoning for verification vision, reasoning architectures for spatial data, 
programming paradigms for spatial reasoning, formal theories of spatial reasoning, spatial 
planning and problem solving. 

Avi Kak 

Robot Vision Lab EE Building- 
Box 121 

Purdue University 
W. Lafayette, IN 47904 

5-9 


Aerospace and Commercial Applications of AI 
Dayton, OH 

Michael Johnson 
The BDM Corporation 
1900 Founders Drive 
Kettering, Ohio 45420 
1513) 259-4434 

14-17 

2nd Inti. Symposium on Methodologies for Intelligent Systems 
Charlotte, NC 

19-23 

2nd Knowledge Acquisition for KBSs Workshop 
Banff. Canada 

Topics to include: Transfer of expertise from experts, manual knowledge acquisition meth¬ 
ods and techniques, apprenticeship learning techniques, issues in cognition and expertise 
that affect the knowledge acquisition process, induction of knowledge from examples, and 
knowledge acquisition methodology and training. 

Jeffrey Bradshaw 
Advanced Technology Center 
Boeing Computer Services 
PO Box 24346 
Seattle, WA 98124 

28-30 

AI East 

Atlantic City, NJ 
Tower Conference Management 
November 1987 
1-6 

Advances in Intelligent Robotics 

Hyatt Regency Cambridge 
Cambridge, MA 

Conferences on: Optics, Illumination and Image Sensing for Machine Vision: Intelligent 
Robots and Computer Vision; Space Station Automation, Automated Inspection and High 
Speed Vision Architectures; and Mobile Robots. 
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SPIE Technical Program Committee/Robotics ’87 
P.O. Box 10 
Bellingham, WA 98227 
(206) 676-3290 Telex 46-7053 

9-12 

1987 International Conference on Computer Aided Design 
Santa Clara, CA 

Topics to include systems, simulation, layout, and test of CAD 
systems for electronic circuit design. 

ICC AD-8 7 Secretary 
Mentor Graphics Corp. 

1940 Zanker Road 
San Jose, CA. 95112 
(408) 436-1500 

30-Dec 2 

IEEE Workshop on Computer Vision 
Fountainbleau Hilton, 

Miami Beach, FL 

Keith Price 

Institute for Robotics and Intelligent Systems, 

MC0273 Electrical Engineering - Systems 
University of Southern California 
Los Angeles, CA 90089 
(213) 743-5526 

EMAIL: price@ganelon.usc.edu 

December 1987 

9-11 

Frontiers in Computing 
Amsterdam, The Netherlands 

Latest developments in Numerical and Symbolic Processing, 
Parallel Computing, Optical, Molecular, and Biological 
Computing. 

Frontiers in Computing 
do CWI 

P.O. Box 4079 1009 AB 
Amsterdam, The Netherlands 

January 1988 
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21st Annual Hawaii Inti. Conference on System Sciences (HISC 
21) Kona, Hawaii 

Topics to include: Automatic Deduction, Knowedge Representation, Learning, Natural 
Language, Planning, Rule-based Systems and Search, as applied to software design and 
implementation with emphasis on large-scale software systems. 

Prof. Gail E. Kaiser 

Columbia University Dept, of Computer Science 
New York, NY 10027 
(212) 280-3856 

EMAIL: kaiser@cs.Columbia.eu, ...!columbia!cs!kaiser 

NEURAL NETWORK DEMONSTRATION PROGRAM AVAILABLE 

By Shirley Bockstahler-Brandt 
AISIG Steering Committee 

I have translated (most) of Jorgensen’s neural net program to VAX Fortran. It does work 
and can offer some insight into how neural nets work. 

For those of you who did not make it to Nashville, Jorgensen was one of our speakers at 
the Symposium. He passed out copies of a simple net simulation written in Basic. The 
software may be "freely used for educational purposes only." 
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FROM THE EDITOR 


That's right . . . singular, not plural. 

At the spring DECUS symposium in Nashville this past April, we 
were delighted to learn that our long-time SIG chair, Tom Provost, 
had been elected to the DECUS Board of Directors. As a result. 
Bill Walker, my illustrious partner-in-crime on this rag, got 
kicked upstairs to the SIG chairmanship—and yours truly became the 
editor of the HMS Newsletter. 

What does all this upheaval in the ranks of the HMS SIG mean? 
Well, as far as the newsletter is concerned, hopefully not too 
much. I'm implementing a few graphical changes: Starting with 
this issue, the newsletter will have a name (HARD NEWS) and start¬ 
ing with the next issue (or whenever I get the cartoon done), a 
mascot. But the publication's mission will remain the same—to 
provide you with good, solid technical information about DEC and 
DEC-compatible hardware. I plan to put out at least six issues in 
1987-88, material (and sanity) permitting. 

This issue of HARD NEWS contains quite a few tantalizing tid¬ 
bits from the Nashville symposium, including some extremely helpful 
information about living with the TK50, and a summary of recent 
FCOs and ECOs. Look for more goodies from Nashville over the next 
few months. 

Of course, things do happen outside DECUS symposia, and HARD 
NEWS always appreciates contributions from readers, especially of 
the hints-and-kinks variety. There is a form at the back of the 
book that tells you how to send your material to the newsletter. 
The deadline for the next issue is July 24, 1987. 

Carmen Wiseman 
Editor 


HMS-2 






TK50 PROBLEMS AND SOLUTIONS 


EDITOR'S NOTE 

This material has been excerpted from a Nashville DECUS 
presentation by Digital product developer Bernie Ruck. 
More material from Bernie's excellent presentation will 
appear in future issues of HARD NEWS. 


PROBLEM SOLUTION(S) 


Thermal cut-out (a rare 
occurrence in normal 
operation) 


o Drive requires 5 cfm of 
air. Thermal sensor may 
cut out if system cover 
is removed or TK50 bench 
is tested without cooling 
fan 

o Drive automatically recovers 
when it cools down 


******************************************************************* 
Leader-latching failures; 
caused by; 

-Dropped cartridge (leader) o Operator inspects for 

misplaced) leader position 

o Design change to o Design change to 

tolerance to shock increase tolerance 

to shock 


-Tolerance stack 


-Power off with 
cartridge inserted 


o Code and mechanical 
design improvements 

o Remove cartridge before 
power down 


Cartridge cannot be fully 
inserted? caused by; 


-Hesitation during 
cartridge insertion 


o Insert cartridge fully 
to mechanical stop 
o Cartridge shell redesigned 
to accommodate tentative 
insertion 

o To recover, remove 

cartridge, drop handle, 
and push button twice to 
clear error 
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-Faulty repair: buckling 
link caught under receiver 


o Be certain buckling link 
is fully retracted 


******************************************************************* 


Handle can't be lifted 
to remove cartridge when 
green light is on 


o Problem can be avoided 
by lifting handle only 
when green on/red off 
o Latest drive code will 
automatically reset 
drive 

o To recover, cycle 
cartridge to BOT by 
pressing switch in and 
out once 




Cartridge can't be 
removed from drive after 
handle forced open with 
red light on 


o Avoid by not lifting 
handle until green on/ 
red off 

o To recover, lower handle 
and press switch in and 
out twice to clear error 


******************************************************************* 

Terminal hangs with error 

message "MUAO not software 

enabled" (phantom device 

MUA4224); caused by: 

-Inserting cartridge o Load tape before issuing 

while MOUNT or INIT MOUNT/INIT commands 

command is executing o Fixed by FCO to controller 

code 

o To recover, reboot system 

******************************************************************* 
Brand-new cartridge can't 
be mounted and drive 
error results; caused by: 

-Test patterns left on o To recover, clear drive' 

cartridge that confuse error, remove cartridge, 

drive and either degauss it 

or return it to Digital 


EVERYTHING YOU EVER WANTED TO KNOW 
ABOUT THE MICROPDP-11/53 


KDJ11-DA 


MICROPROCESSOR 


DCJll-AC 


BOOT ROMS 


Version 1.0: LB 23-204E5-00 (there goes that 
HB 23-205E5-00 Micronote!) 
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This version supports standard ASCII characters in English and 
Spanish. Standard terminals and settings can be used. 

Version 2.0: LB-23-261E5-00 
HB-23-262E5-00 

This version supports both standard ASCII characters and the DEC 
Multinational Character Set (MCS), which VT220s set to VT200 mode 
will accept. The version 2.0 ROMs support most "normal" 
languages—sorry, no Chinese, Japanese, Korean, Hindu, etc. 

RQDX3 Version 2.9 microcode 

FORMATTER ZRQCCO 

RD31-A Top drive jumpers (view from rear): 

(REV. 1A) 


Bottom drive jumpers (view from rear): 


The top drive's read/write board has a plug-in connector, which 
appears to be a terminator of some sort. When adding or replacing 
an RD31 drive, users must be aware of the plug and either transfer 
it from the old drive to the new one—or be ready to purchase a new 
drive. It's very easy to invert the drives or screw up the 
terminator or drive-select jumpers when attempting to add a second 
drive to a single-drive 11/53 system, so watch out! 

The cables are standard BA23 cables (17-00286-00 and 17-00282-00). 
There's one crucial difference: The cables for drive zero havfe blue 
headers, while those for drive one have gray headers. 


RX33 Bottom drive jumpers: 

(REV. Al) 

DS0 
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FCO/ECO CORNER 


In this space, we're going to try to keep you apprised of DEC field 
change orders (FCOs) and engineering change orders (ECOs) as we 
hear about them. (The difference, of course, is that ECOs are 
taken care of at the factory and FCOs require intervention by your 
friendly field service rep.) A few items from the Nashville sympo¬ 
sium follow. 

KA630 (M7606-AH) 

Under Ultrix-32m version 1.1, this MicroVAX II/VAXstation II CPU 
board exhibits a system crash bug. The error is logged on the sys¬ 
tem console and in Ultrix system message file machine check 80. 
ECO No. M7606-ML006 (dated April 4, 1986) corrects the problem by 
replacing funky memory chips. 

To make sure you have an OK board, look for a module numbered 
M7606-AS (a new build with NEC chips), M7606-ZS (a reworked 
M7606-AH with NEC chips), M7606-ZF (a reworkd M7606-AH with Hitachi 
chips), M7606-ZC (a reworked M7606-AH with Fujitsu chips), M7606-AP 
(a new build with Mitsubishi chips), or M7606-ZP (a reworked 
M7606-AH with Mitsubishi chips). 

Wait, there's more: yet another ECO for this much-plagued 
module. ECO No. M7606-ML007 (dated November 10, 1986) fixes some 
typos on the circuit schematic and replaces a low-yield DC333 chip. 

KDJll-A 

The dual-height MicroPDP-11/73 CPU module exhibits a bus-contention 
problem when the DCJll exits from an FPJll-provoked stall while a 
DMA bus transaction is current. ECO No. M8192-TW007 (dated Oc¬ 
tober 7, 1986) corrects the condition by reworking the boards and 
updating the documentation. 

MICROVAX MEMORY BOARDS 

Mike Allen, HMS Symposia Coordinator, has learned from his DEC 
field service rep that there is a problem with some of the "older" 
MicroVAX II CPUs and memory boards. The following FCO list shows 
which field change order (FCO) applies to which module: 


o MicroVAX II CPU with module no. M... AH — EQ-01358-01 
o DEC 1MB memory board M... BH -- EQ-01358-02 

o DEC 2MB memory board M... BH — EQ-01359-01 

o DEC 4MB memory board M... BH — EQ-01359-02 
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Look for the module number on the metallic spine of the board. 

If you have any of these boards, DEC field service will re¬ 
place them free. Use the FCO number if you need to clarify things 
with your field service person. 

Rumor has it that the reason DEC is replacing these modules is 
because the third-party memory chips used on the listed boards 
don't meet specs. 


NIBBLES AND BITS 


If you've been wondering what happened to MicroNotes, wonder no 
longer. DEC printed up a new edition around the beginning of June 
1987 —and we hear that it was the last to carry the MicroNotes 
moniker. 

The June MicroNotes included a software features comparison, a 
comparison of Digital system buses, and a KXJll-CA performance com¬ 
parison, as well as information about DMA on the MicroVAX II, 
VAX/VMS real-time programming and RQDX controllers. 

A new name for the publication hasn't been selected yet, but 
Applications Notes might be a possibility. Whatever it ends up be¬ 
ing called, it will come out in June and December, and will go to 
the current MicroNotes mailing list. Stay tuned for further 
developments. 


SUBMITTING ARTICLES TO HARD NEWS 


The purpose of HARD NEWS, the HMS SIG newsletter, is to 
serve as a forum to share information related to DEC 
hardware with the members of the SIG. As such, the 
existence of the newsletter is entirely dependent on your 
contributions. If you have an HHK item, a better or safer 
way to do something, product news, a tutorial article of 
general interest, etc., we are interested in publishing it 
in the newsletter. It is intended that HARD NEWS be 
published at least six times a year. 

You can submit material to the editor, Carmen Wiseman, or to 
the HMS SIG chair. Bill Walker. We can accept submissions 
in a wide variety of formats: 


o Items can be sent to the editor on VMS-format RX50s, 
TK50 cartridges, or IBM PC format 5 1/4" floppies. The 
SIG chair prefers RT-11 floppies but can handle any 
reasonable media. 


o 


Hard copy, like cash, is always 
Camera-ready copy will save us a lot of 
don't insist on it. You can also use 
Submission Form in the "Questionnaires" 
combined SIGs Newsletters. 


acceptable. 
typing, but we 
the Hardware 
section of the 


o Those of you with access to DCS can send things to 

WALKER or WISEMAN. DCS is usually checked on a daily 
basis. 

o You can reach the SIG chair on CompuServe as 

"Bill Walker 71066,24" or via EasyLink mailbox 62752448. 
You can reach the editor via EasyLink mailbox 62960090 
(be sure to say ATTN: or TO: Carmen Wiseman somewhere 
in the message). 


If you have anything to submit, send itl If it is a mess, 
but we can read it, we will get it into the newsletter 
somehow. Finally, if you have any questions about 
submitting material, call one of us. The telephone numbers 
are listed below. 


Contributions can be sent to: 


William K. Walker 
Monsanto Research Corp. OR 
P.O. Box 32 A-152 

Miamisburg, OH 45342 
(513) 865-3557 (work) 

(513) 426-7094/0344 (home) 


Carmen D. Wiseman 
Digital Review 

Prudential Tower, Suite 1390 
800 Boylston Street 
Boston, MA 02199 
(617) 375-4361 (work) 
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CONTRIBUTION GUIDELINES 


From the Editor's Terminal 


Contributions for the newsletter should be sent to: 

Frank R. Borger 
Michael Reese Medical Center 
Department of Radiation Therapy 
Lake Shore Drive at 31st St 
Chicago, IL 60616 
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Contributions of letters, articles, important SPR's etc will be 
accepted in any form, (including notes jotted in pencil on 
gravy-stained tablecloths.) Contributions will be much more gra¬ 
ciously accepted in one of the following formats: 

1. Non machine readable sources, (SPR's etc,) should be reason¬ 
ably dark to insure good photocopying. Text whatever should 
be the equivalent of 66 lines at 6 lpi, with 4 T line top mar¬ 
gin, 5-line bottom margin, left-margin 10, right margin 74 
at lOcpi. If using a DEC LN03 for output, use left-margin 8. 
right margin 72. 

2. Machine readable sources may be submitted on 9-track 

Mag-tape, (800,1600, or 6250 BPI,) DEC-tape II, DecMate 
floppies, or whatever. We're not fussy, we'll even accept 
paper tape or cards. Preferred format is DOS or BRU for 
tapes, Files-11 for DEC-tape II. 

3. 1200 baud dial-up modems are available on our IAS system and 
our VAX, with KERMIT servers available. Give the editor a 
call at (312J-791-2515 (preferably later in the day,) to ob¬ 
tain access information, etc. 

4. If long distance dialout is not possible on your system, 
we'll be willing to call your system and do the work, (un¬ 
less you want to transfer the entire manual set at 300 
baud. ) 


Any media sent to us will be promptly returned. 


ASK THE DEVIAS WIZARD 


It's only co-incidence I'm sure, but the only time we have 
hardware problems is right around deadline time. Last month it 
was the disks and the LN03, (Rover at least looks normal again, 
a couple of days and 1200 bucks later.) This month we're just 
coming back to normal from an air conditioning failure that oc- 
cured late Saturday AM, and left the room at 100 degrees plus. 
DEC makes damn good hardware. Our 11/44 system came right back 
up, (although we pinched a disk cable when we closed things up, 
after opening the racks to do some service,) and our 13 year old 
11/45 only lost one power supply.) We're running on a loaner air 
conditioner that can't hack the load and room temp is up in the 
80's, and the equipment is solid. Oh well, what do you expect 
of your editor's THIRTEENTH issue. At least they finally seem 
to have fixed the leaks in the roof, (the NEW roof that is,) 
that caused rain water to pour onto the printers and the CPU. 

This month's program of the month is a simple basic program to 
turn the printer port on a VT100 or VT220 or compatible terminal 
on or off. It is especially nice because it lets you use the 
"Print scrolling region only" function, which works great for 
accessing the Digital Store and getting hard copy, etc. 

An IAS user who sent in a membership survey form mentioned that 
they wanted command line recall. Any users interested in this 
should look at our ECR, (Editing Console Routine.) An abstract 
is included herein. The program is available from DECUS, 
(11-870,) and from the Spring IAS/RSX sig tape. We will also 
push to get our fearless leader to submit his version of command 
line recall to the library and the sig tapes. 

Finally we have the slides for the guide to an IAS handler talk 
from the Spring DECUS. 

Now that Summer is here, the air conditioners are breaking down. 


If you have a problem you would like to submit to the Devias 
wizzard, write a letter or fill out a copy of a standard SPR and 
send it to the Editor at the above address. Answers to problems 
from members (or anyone) should also be sent to the Editor. 
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Ten Years Ago Today 


The Program of the Month 


The August 1977 Multi-Tasker contained: 

A letter from a user trying to move from RSX11D version 6B to 
version 5.2 stated among other problems: 

1. The DSC utility does not work on files generated by 
version 6.B. They booted the new distribution tape and 
DSC'd their system disk to 6 TU10 mag tapes, then put a 
fresh disk in, BAD'ed it, and copied everything back to 
their system disk. After running for a week or so, 
they started to see corruption of their system disk. 
(Strangely enough, they never mentioned using VFY to 
check their disks.) 

2. Tasks running under Time Slicing sometimes took up to 5 
minutes to load. 

3. The heavily overlaid 6.2 task builder was much slower 
that under 6B. 

4. As with 6B, they were never able to get preserve to 
work properly with their system, (11/70, TU10, DB: 
disks.) 

The resumed "New Installations" section listed a very interist- 
ing new user. An Australian installation, consisting of an 
11/70 with all of 128K words, (they were hoping to expand to 
192K,) two TUlO's, (one 9-track one 7-TRACK,) and several termi¬ 
nals. Among the shortcomings they mentioned were being one of 
only 3 IAS users in the whole of Australia. 

A report on the IAS workshop at the Spring Boston Symposium 
stated that there were about 50 IAS users present, compared to 
19 at the fall Las Vegas Symposium. Some of the things in the 
IAS wish list were: 

1. Improved file backup facilities, including incremental 
backup and migration of unused files to tape, (archiv¬ 
ing. ) 

2. Improved batch, including conditional execution, sub¬ 
mission of batch jobs from programs, routing of batch 
output to a file rather than a printer, and better mon¬ 
itoring . 


MICHAEL REESE MEDICAL CENTER - DEPARTMENT OF MEDICAL PHYSICS COMPUTER 

LISTING OF DR2:[102,006]PRON.BAS;ll ON 25-JUN-87 AT 14:06:30 PAGE ! 

10 print "Printer on menu. Enter selection number" 

20 print "0= Buffered copy print" 

30 print "1= Buffered transparent print (does not show on screen)" 

40 print "2= Bi-Directional copy print mode" 

50 print "3= Bi-Directional transparent print mode" 

60 print "4= Auto print mode" 

70 Print "Enter choice";:input i 

72 print "Print scroll region/full screen (l=Scroll region)?";:input ; 

80 if i<0 goto 10 

82 if i>4 goto 10 

84 if i=l goto 200 

86 if i=2 goto 300 

90 if i=3 goto 400 

92 if i=4 goto 500 

100 print chr$(27);"[?7ibreak 

110 goto 999 

200 print chr$(27);"[5ibreak 
210 goto 999 

300 print chr$(27)?"[?261";chr$(18);:break 
310 goto 999 

400 print chr$(27);"(?26h";chr$(18);:break 
410 goto 999 

500 print chr$(27);"[?5ibreak 

999 if j=l then print chr$(27);"[?191":break 

1000 exit 


MICHAEL REESE MEDICAL CENTER - DEPARTMENT OF MEDICAL PHYSICS COMPUTER 

LISTING OF DR 2 :[ 102,006] PROFF.BAS; 7 ON 25-JUN-87 AT 14:06:39 PAGE 1 

10 print chr$(27);"[?4i";chr$(27);"[4i";chr$(27);"[?19h";: break 
20 exit 


3. Improvements to CLI's including parameter passing to 
indirect files, editable PIP directory output, provi¬ 
sion for user added PDS commands. 
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ECR, Enhanced Console Routine 


ECR Enhanced Console Routine 

AUTHOR: F. Borger, Michael Reese Medical Center, Chicago, IL 
Operating System: IAS, Version 3.2 
Source Language: MACRO-11 


Abstract: ECR is an intelligent monitor console routine. It 

is an enhancement to the AUX program as originally written by 
Robin Miller for operation on RSX. It provides the following 
enhancements. 

o The last 20 command lines can be recalled and edited. 

o Often used commands are defined by numeric keypad keys. 

o Up to 48 command line mungers can be defined. Typical uses 
for these would be to define a command that expands: 


KEF NAME 

to 

KED 

NAME.FOR 

FOR NAME 

to 

F77 

NAME,NAME/-S P/CR=NAME 

LINK NAME 

to 

TKB 

@NAME.CMD 


o A default file name option lets ECR remember the last name 
used and use it again if no name is given in the command. 
This would further reduce the commands required to edit, 
compile and link a fortran program to the following: 

KEF NAME 

FOR 

LINK 

As an added goodie, we have included the program QUOTE. This 
is a cookie/dammit program that provides notable quotations 
such as: 

"Now we've got them. - Custer at the Little Big Horn" 


Distribution: 600' 1600bpi magtape, BRU format 
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An 

Introduction to 
Writing an 
IAS Device Driver 


( 1018 ) 


Normal Program APR Mapping 
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Privileged Program APR Mapping 



Handler APR Mapping 
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QIO Interface 



Unit Identification Table (UIT) 



Dispatch Table Address 
Max/Actual Number of Units 
Last Normal/Express Request 
Reserved 
Reserved 

Unit Number or Validity Mask 
Normal Request Node Pointer 
Express Request Node Pointer 
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Dispatch Table 


DECLARING HANDLER RESIDENCY 



Send/Request Failure address 
Send/Request Success address 
Volume Characteristics Mask 
Function Handler address 


init: 


mov 

mov 

mov 

call 

call 


#uit,rO 
#"XX,r2 
#uf.rh,r3 
<3#. .dsut 
<3#..dsmu 


ALLOCATING UMR’S 


Initialization 


Declare Handler Residency (..DSUT/..DSMU) 
Connect to Interrupt Vector (..CINT) 

Perform specific and/or Peculiar Initialization 
Specify a Power Recovery AST (SPRA$) 


bitb 

#on.um,umr22+l 

beq 

10$ 

;dont need 

mov 

#1 ,r3 

;get 1 

mov 

r3,mrb+m.df 

;save->mrb 

call 

..ural 

;get 1 

bcc 

5$ 

;br if OK 


mov 

r3,mrb+m.pw ;save slot 

clc 

;show succ 

return 
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UMR MAP REGISTER BLOCK 


.blkw 6 

m.rn ;owner’s req node add 
m.pw ;pre-allocated slot/len 
m.df ;# of pre-allocated 
m.sl ;slot/length word 

m.ul ;low 16-bit address 

m.uh ;high 2-bit address 


SETTING UP POWER FAIL AST 


mov 

#uniten,r4 

;lst unit 

mov 

(r4),r5 

;pud ptr 

beq 

failed 

;no pud 

mov 

#pwr,-(sp) 

;push dpb 

emt 

377 


bcc 

pfok 

;br if ok 

jmp 

exit 


pwr: 

spra$ 
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CONNECTING TO INTERRUPTS 


mov 

#uniten,r4 

first unit 

mov 

(r4),r5 

pud add 

mov 

u.tv(r5),r0 

vect add 

mov 

#isrin,rl 

isr add 

clr 

r2 

isr base 

clr 

r3 ; 


bis 

u.ip(r5),r3; 

priority 

call 

@#. . cint ; 

connect 

bcs 

exitcf i 

if failed 


possibly 2nd connect here 
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Main Code 


WAIT! 

Perform I/O Completion (JODN) 
Dequeue a request (..DQRN/..DQRE) 
I/O Function in Dispatch Table 
Validate Function (..VACC) 

Data Transfer 

..VXFR 

Transfer is to/from contiguous memory 
Transfer is to read/write memory 


..BLXI/..BLXO 

uses APR3 as scratch area 

R1 = Request Node Address 
R2 = Virtual Starting Address 
R3 = Transfer Byte Length 
R4 = Handler Address 
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10 FUNCTIONS 


mov 

r-.pb(rl) ,r2 

;start 

mov 

r.pb+2(rl),r3 

;length 

bit 

#on.um,.umr22+l;22bit? 

beq 

18bit 


call 

..vxur 

;..vxfr 

bcs 

error 


mov 

r4,r.pb(rl) 

;change 

mov 

r5,r.pb+2(rl) 


mov 

r3,r.pb+4(rl) 


mov 

r2,-(sp) 


mov 

#mrb,r2 


call 

<3#.. almr 


mov 

m.ul(r2),r5 

;low 16 

mov 

m.uh(r2),r4 

;high 2 
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DOING THE TRANSFER 

1/ Let the system do the walking 

mov r.pb(rl),r2 

mov r.pb+2(rl),r3 

mov #mybuff,r4 

call ..blxi/..blxo 

2/ Do it yourself: 
r5 = low 16 bits 
r4 = high 2 bits (bit 4,5) 


ash 

#-4,r4 ; 

shift 2 down 

ashc 

#12,r4 

back up 

ash 

#-12,r5 ; 

justify it 

bic 

#177700,r5 ; 

mask garbage 

add 

#offac3,r5 ; 

apr offset 

mov 

#cpdr3,-(sp) 

- 

mov 

r4,-(sp) 


call 

..spd3 ; 

swap par/pdr 

mov 

(sp)+,oldpar 

mov 

(sp)+,oldpdr 


10 COMPLETED 


mov 

r2,-(sp) 


mov 

r4,-(sp) 


clr 

r2 

;adjust dec 

mov 

number,r4 

; number sent 

call 

(3#.. iodn 

;all done 

mov 

#mrb,r2 

;for umrs 

call 

@#..demr 

;give back 

mov 

(sp)+,r4 


mov 

(sp)+,r2 
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Exiting (Gracefully) 


Do final housekeeping and cleanup 

Turn off interrupt enable bits 
release all nodes used 

Disconnect from all interrupts (..DINT) 

Declare Nonresidency (..DNRC) 

EXIT$S 

What to Watch for 

Read only code 

MACRO-11 .PSECT Specifications 
Adjusting your stack 

MOV #HERE, SP 

HERE: 

The "NEW" SCOMM 
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EXITING &/0R BAILING OUT 


mov 

uniten,rl 

;get pud 

mov 

u.da(rl),rl 

;get hdw 

bic 

#100,Qrl 

;int off 

bic 

#100,4(rl) 

;(both) 

mov 

uniten,r0 

;unit en 

mov 

u.tv(rO),r0 

;trap vec 

call 

@#..dint 

jdisconne 

add 

#4,r0 

;to xmit 

call 

<9#. . dint 


mov 

mrb+m.pw,r3 

;umrs 

call 

0#..urda 

jdealloc 

mov 

#uit,r0 


call 

0#..dnrc 

;non res 
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Next month's theme - DECNET/E 


From the Editor 
Terry Kennedy 


"I don't think there's anybody back there” 

The above phrase may have been made famous by a fast-food 
chain's advertising, but recently I have heard (and thought.) 
the same thing about some areas of DECUS, particularly this 
SIG. This impression was caused by several things: Our SIG's 
section in the newsletter was sporadic at best, and seemed to 
contain mainly reprints of articles. There seemed to be no 
editorial direction. When I called some of the SIG leaders to 
ask why this was, I found that many of the SIG leaders had 
changed jobs, or were otherwise unreachable. I developed a 
view of the SIG as a remote, detached entity. The SIG leader I 
finally reached told me "Go to the Nashville Symposium - you'll 
change your mind.” 

He was right - I have to tell you that there is a VERY 
active RSTS SIG. If you go to the symposia, you already know 
this. For those of you who have never attended, it's a real 
eye-opener. Our SIG had about two dozen sessions, which were 
very well attended. Almost all sessions had extensive 
handouts. I found the SIG leadership to be very involved and 
responsive. 

However, that doesn't do a lot for the 90% or so of the 
DECUS membership who cannot attend symposia. That's where this 
Newsletter comes in. I volunteered as Editor because I was, 
until recently, one of that 90%. My job is to communicate to 
you the activities of the SIG, and spread around some of the 
material generated by the symposia. 

As my first task, I have updated the SIG listing in the 
back of the Newsletter. You should notice that the information 
for each person is now more complete. If you have a need to 
communicate with one of the SIG leaders, you now have the 
information you need. However, it is generally unreasonable to 


expect extended return long-distance telephone calls or free 
advice regarding non-SIG topics. More on advice later... 

Each issue after this one will have a theme topic (for as 
long as I can come up with good themes). Next month's theme 
will be DECNET/E. Please feel free to suggest topics, or 
especially to submit articles. Remember, each newsletter is 
only as good as the articles submitted to it. 

I would like to thank the SIG leadership for providing a 
newsletter during the time that there was no editor. 


Newsletter Dialup System now Available 


As of now, the RSTS SIG has a dedicated system available 
for the electronic submission of articles (hint hint), letters 
to the editor, etc. The Spring/Fall combined SIG tape is also 
on-line and available for downloading. KERMIT is available for 
uploading and downloading files. To use the system, dial (201) 
435-2546 at either 300 or 1200 baud. Hit a few RETURNS until 
you get the RSTS banner, then sign on with account 2,1. No 
password is required. You may request a private account by 
sending MAIL to NEWS. If you need help or advice on some 
aspect of RSTS, you can leave a message to NEWS as well. I 
will try to answer all questions I get. In order for you to 
receive a reply, I will need a 'real' address to send it to. 
Any questions submitted may be published in the Newsletter if 
considered of general interest. 

The system is up 24 hours a day, seven days a week, except 
after power failures, which seem to happen too often. If you 
are having a problem with the system, call (201) 435-1890 and 
leave a message. This is a VOICE number, not a DATA number. 


Readers Desperately Needed 

Did you know that the information in this newsletter 
reaches a very small percentage of RSTS users? That means that 
they'll be missing all of this information we'll be publishing 
- information which will make them more productive. You 
already know the benefits of subscribing, so you are our best 
way to reach these people who aren’t DECUS members, or who 
don't subscribe to the Newsletter. 

If you know of another RSTS site where there isn't a DECUS 
member, give them the DECUS application and newsletter 
subscription form found in the back of this issue. 
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DCL Trick of the Month 


Questionnaire 


Every SIG seems to be publishing DCL ’goodies’ lately. 
I'll try to have some of the more interesting ones here. As 
usual, this is not restricted to RSTS DCL, any DCL trick will 
be included. However, preference is given to RSTS-unique ones. 

This month's trick is with SET VERIFY. It is only 
available on RSTS 9.0 and later. In addition to turning console 
logging of commands on and off, it can show you the command 
line after symbol substitution: 


$ DISPLAY == "SHOW” 
$ SET VERIFY/DEBUG 
$ DISPLAY NETWORK 
(SHOW NETWORK) 

... output ... 


define display as a synonym for show 
turn on debugging display 
issue command 

displays substituted command 


It can also show you the actual command that DCL issues to 
perform the task: 


S SET VERIFY/WATCH J turn on translation display 
$ SHOW NETWORK l issue command 

(NCP SHO ACT NOD) ! displays actual command issued 
. .. output ... 

These two options can be very useful when you have a 
command procedure which isn't acting as planned. The /DEBUG 
option will rapidly show you if you are experiencing undesired 
symbol substitution. The /WATCH option will show you exactly 
what command is being executed - in the example above, it 
explains why DECNET/E only shows active nodes rather than all 
nodes, which would be NCP SHO KNO NOD. 


Next month. I'll show you how to use /WATCH to locate 
commands in DCL and change them. 


Software Problem Report (SPR) Log 

Please send the newsletter editor copies of any SPR’s (and 
Digital's answer) on RSTS/E, DECNET/E, or RSTS layered 
products. We will print any that are of general interest. The 
reason for this is that many SPR's are answered with a patch or 
a notice of restriction, but due to space considerations, they 
are not published in the Software Dispatch. Since we're 
desperate for material, this should be useful information and 
we will print it. 


In the back of this newsletter, you will find a 
questionnaire. Please fill it out and return it to the editor. 
This will help us serve you better by defining the areas you're 
interested in. There is a section for your comments, as well. 


CUSP of the Month 

Every month, we'll pick a CUSP (Commonly Used System 
Program) and show you new things to do with it. This may be 
either in the form of patches, or simply a new way to use it. 
When we provide modifications to the source, we will only show 
the lines which need to be changed. If you decide you want the 
patch, edit a COPY of the program (NOT the original). Please 
remember that Digital can't be responsible for modified 
programs. 

This month's victim is SYSTAT.BAS. This is a reprint of 
an earlier patch which allows the 'account name’ field of a 
user's account to be displayed for each job. The author of the 
patch is Mark Hartman, of Jadtec Computer Group. 

Modify the line as indicated by underscored text: 

"Job";TAB(6%);"Who";TAB {13%) ;"Name” ; TAB( 26%) ; "Where";TAB( 33 %);& 
"What";TAB{ 41%) ?"Size";TAB (47%) ;"State"rTAB( 56%) ;"Run-Time"; & 

\ IF PRIV.TUNE% THEN & 

PRINT #0%,TAB (66%) ;"Pri/RB";TAB (75%); "RTS" & 

ELSE PRINT #0%,TAB( 68%) ;"RTS" & 

Replace the line: 

\ PRINT #0%,TAB (3 %); S0$ ;TAB(9%-C%);S$; & 
with: 

\ PRINT #0%, S0$,* SPACES(5%-C%) ;S$; & 

\ PRINT #0%, SPACES(8%-(LEN(S$)+(4%-C%))); & 

\ PRINT #0%, FNACCOUNT.NAMES(PROJ%,PR0G%);" "; & 

Modify the line as indicated by underscored text: 

\ PRINT #0%,TAB( 26%) ; S$ ;TAB (33%) ? RAD$(UU.SYS0%(17%)+ & 

SWAP%(UU.SYS0%(18%)));RAD$(UU.SYS0%(19%)+SWAP%(UU.SYS0%(20%)) ) ;& 
TAB(39%) ,*FNNS(4%+PRIV.TUNE%,UU.SYS1%(13%)); & 

\ PRINT #0%,"/";FNN$(2%,UU.SYS1%(19%)); IF PRIV.TUNE% & 

\ PRINT #0%,"K";TAB( 47%); & 

Modify the line as indicated by underscored text: 

\ PRINT #0%,TAB(55%-(PRIV.TUNE%*9%)-((NOT PRIV.TUNE%)*2%)); & 
RADS(UU.SYS0%(27%)+SWAP%(UU.SYS0%(28%))); & 

Add the following before line 15100: 

15010 DEF* FNACCOUNT.NAMES(PR0J%,PROG%) & 

\ ON ERROR GOTO 15020 & 
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\ Z$ = SPACES (13%) & 

\ LSET Z$="<No name>" & 

\ LSET Z$ = "<Logged out>" if proj%=0% and prog%=0% & 

\ LSET Z$=CVT$$(MID(SYS(CHR$(6%)+CHR$(-2 5%)+CHRS(-1%)+CHR$(5%)+& 
CHR$(PROG%)+CHR$(PROJ%)+STRINGS(16%,0%)+”SY M + & 

STRINGS(2%,0%)),8%,13%),5%) UNLESS PROJ%=0% AND PROG%=0% Sc 
\ GOTO 15030 & 

15020 RESUME 15030 & 

15030 FNACCOUNT.NAME$=Z$ Sc 

\ ON ERROR GOTO 19000 & 

\ FNEND & 

1 RETURN THE ACCOUNT NAME BLOCKETTE DATA Sc 

You should then re-compile SYSTAT with Basic-Plus 2 (if 
you have it) or Basic-Plus. If you don't use BP2, you will 
have to rename SSYSTAT.TSK to something like $SYSTAT.OLD so 
that RSTS will use SSYSTAT. BAC. The output of SYSTAT will then 
look like the following: 

RSTS V9.x-yy SPCCSPDP status at 27-Jun-87, 10:47 PM Up: 2:01:06 


Job 

Who 

Name 

Where 

What 

Size 

State Run-Time 

1 

1,2 

(SYSTEM) 

Det 

ERRCPY 

5/64K 

SR 

NSw 1:11.2 

2 

1,2 

(SYSTEM) 

Det 

NPKDVR 

9/64K 

SL 

54.6 

3 

1,2 

(SYSTEM) 

Det 

PBS. . . 

19/64K 

SL 

3.1 

4 

1,2 

(SYSTEM) 

Det 

EVTLOG 

18/64K 

SL 

2.6 

5 

1,2 

(SYSTEM) 

Det 

MAILQ 

32/64K 

SL 

18.6 

6 

1,254 

Terry Kennedy KB26* 

SYSTAT 

15/64K 

RN 

Lck 8.5 

7 + 

1,3 

Operator 

Det 

DISPLY 

17/64K 

SL 

5:50.8 


Of course, the rest 

of the 

display 

has been * 

truncated. You 

may 

now want 

to set the 

[1,2] account' s 

name to ' 

(SYSTEM)' as I 


have done here. 
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Food for Thought 


"DECtape I I , TU58, is a low cost mass memory device offering 
random access on block-formatted, pocket-size cartridge media. 
DECtape II is ideal for small system mass storage, diagnostic 
loading, and software update distribution." 

{Any 11/44 or VAX 7 50 owne r will tell you so ...) 


Digital Equipment Corporation 
PDP11 Peripherals Handbook 


The Editors Corner 

Bruce R. MitcheI I 


Oh, my word, it's hot out here in Minnesota. It’s so hot 
that the gophers aren't coming out until midnight, and then only 
for short sprints to the nearest corncrib. The carp have all 
packed up and left for parts south of here. Even the mosquitoes 
- the venerated Minnesota State Bird - are loath to leave their 
nice cool ponds. 

It's so hot out here ... but perhaps we'd better let 
sIeeping dogs lie. 

Ws have more good information for you this month. For those 
of you who program in commercial control environments, check out 
the article on monitoring task status in multitask systems. And, 
of course, the serialization of the 'Hitchhiker's Guide to RSX" 
continues. That pretty well fills up the 40 page quota for this 
issue. NMiich reminds me ... 

Haul out your fire extinguishers and check the Halon, my 
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dear readership, because this month's editorial dragonflame is 
aimed at YOU. 


- Contributions to the MT - 

Your editor is pleased as can be that more contributions are 
arriving at the plush MT offices. I have a 40 page allocation 
each month, and few things please me more than filling those 40 
pages - few, that is, other than asking for a bigger allocation. 

I do note, however, there are still some of you - yes, I 
must say it - some of you who haven't yet written an article for 
the Multi-Tasker. 

So maybe it's time again to blast away what appear to be 
corrmon misconceptions about writing for this publication: 

o You do not have to be a genius or wizard to write an article. 

o Nobody laughs at articles submitted to this newsletter. 

o No article submitted is ever too elementary to publish. 

o No article submitted is ever too short to publish. 

I f you send me something for the Multi-Tasker, it will be printed 
in the first available issue, or I wiII see that it gets to the 
editor of the appropriate newsletter. 

Some of my correspondents complain that there aren't enough 
introductory, how-to, non-technicaI and general interest 
articles. There’s a simple explanation: The people who submit 
now are interested in the technical side of RSX. They know the 
basics, so they don't want to write about them. They're solving 
today’s problems so that you don’t have to when you come to that 
point. 

If you want to see general interest articles, you have to 
submit them to me. That means you with the newsletter in your 
hands! If you have problems with Indirect or TKB, if you just 
discovered system-wide login corrmand files, if you just found out 
how to bypass Files-11 protection by building a task /PR:0 - come 
on, write it up and send it to me! Great Ghu, what I wouldn't 
give to have an article on A-to-Z! 

I don’t care how rough your writing is. I do my best to see 
that misspellings are corrected, dangling participles are cut 
off, and that code and text is vetted for correctness. But 
without an article to start with, I can't provide these services. 
Come on, you RSX rookies, write! I just love it when there's a 
name I don't know in a byline! 
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Now, here's a challenge for you: I’m no longer going to 
ghostwrite articles. Over the past year, I've ghostwritten at 
least ten articles to fill space. No more. This is your 
news letter, and from this point out, all articles will be your 
articles. You now have 36 pages a month to fill. I'm just going 
to write editorials and glue things together. If nobody submits 
articles, all you will see is the editorial. So write, dammi t ! 

Now, smite the keyboards of your terminals! Don't put it 
off! Show them slimy VAX LUsers what real timers do! And be 
assured that our cause is righteous, our hearts are pure, and 
that if you send me something, future issues will have more than 
just ranting in this column. Thank you. 


- Answer to Last Month's Quiz - 

Embedded in the Editor’s Corner. Congratulations from the 
Multi-Tasker staff, and the entire SIG's best wishes as well, 
Linda! 


- Submitting Articles to the Multi-Tasker - 

Please submit machine readable media. RK05, RK07, RL01/2, 

RM03, RX01/2, RX50, TK25, TK50, 9 channel 800/1600 BP I magtape or 
paper tape are OK. All RSX volume formats are acceptable. 
Anything I can't read I can get converted; don't let that stop 
you from submitting. 

The Editor can now Kermit articles in. The reverse is not 
true; the Multi-Tasker host is normally an isolate. If you want 
to submit via Kermit, call beforehand wi th phone number, login 
for the host machine and system uptimes. 

Submissions which aren't machine readable may take longer to 
get into print. The editor is lazy and types mass quantities 
only once a month when progress reports are due. 

If you preformat a submission in RUNOFF, please set page 
size 58,80; left margin 10; right margin 75; and, when 
changing margins, use incremental changes rather than absolute. 
The editor blesses you for the consideration. 

Send your articles and other submissions to the luxurious 
new Mu Iti-Tasker offices c/o: 

Bruce R. MitcheI I 
4-416 Alfred, St. Mary's 
Mayo Clinic 
Rochester, MN 55904 
(507) 285-5753 


RSX-3 









- And That's The Way Things Are - 

... this month in Pool Lowbegone, where the account file 
password encryption algorithm is strong, the FMS screens are 
good-looking, and the system manager's private TKB priority is 
above average. 


A Cheap Way To Monitor Task Status 

Vincent Moscaritolo 
Datavox Corporation 
9 Pickering Way 
Tancook Crescent, Suite 3A 
Salem, MA 01970 


Ever hear a bank talk? 

RSX can be a very effective solution to the types of 
multi-tasking problems that occur in typical process control 
applications. I would like to describe one way in which I used 
some of the RSX parent-offspring tasking directives in an 
application called Banktalk. 

Bank talk is a voice response system which uses the DECtalk 
DTC03 voice terminals to provide home banking functions. A 
customer can access account data (eg. savings balance), rate 
information, and perform account transactions by calling from a 
Touch-Tone phone. 

A typical system can serve anywhere from one to 64 phone 
lines. Each line is managed by its own DECtalk and its own phone 
server task. Each server task runs under a unique terminal line. 
There is also a monitor task which tracks the status of each of 
the possible 64 server tasks. 

I needed a simple way for each server task to communicate 
its current status (i.e., is it speaking, waiting for a call, 
crashed, etc.) to the monitor task. 


The Server Task Table 

I create a table in the monitor task that maintains 
information about each task. 


Server Task Table Entry Format 


00 

+- 

1 

-+ 

Status 1 

2 

bytes 

02 

H— 

i 

+- 

Taskname in R50 1 

4 

bytes 


TTABLE: 


TSSTAT 

= 0 


; Offset to task status 

T$ ID 

= TSSTAT 

+ 2 

; Offset to task name 

T$LEN 

= TSID + 

4 

; Length of a table entry 

T $MAX 

= 64. 


; Maximum entries in tabl 

. BLKB 

< T $ MAX * 

TSLEN > 

; The Server Task table 


The table format is simple. Each server task maintains an entry 
in the table. The entry describes the task name and the current 
status. 


Given this informat ion, what I need now is some way to fill 
in the status part of the corresponding task's entry. The 
problem is each task is in its own data space and can't access 
the server task table. 


Emi 11ing Status 

RSX provides several ways to communicate between tasks; I 
wanted a cheap one. Fortunately, the CNCT$ and EMST$ directives 
provide us with one such way. The CNCT$ directive allows us to 
make a one way, one time connection between tasks. In fact, this 
connection is closed whenever the connected task either exits or 
emits status. The same mechanism that returns exit status can be 
invoked at any time. In the case of our server task, alI it has 
to do is: 

EMST$S #s tatus 


If things are set up right, "status" can be picked up at the task 
that initiated the connection. Incidentally, "status" is 
preferably some number greater than 4, since 0 through 4 might be 
confused as one of RSX’s reserved task exit status codes. 


0 EXSWAR 

1 EXSSUC 

2 EXSERR 

4 EX$SEV 


Warning; task may have succeeded 

Success 

Error 

Severe error; system may be compromised 


I don't know what happened to status 3, but the above info should 
be in section 4.2 of the Exec reference. 


You might have noticed that in the above EMST$ example I did 
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not specify any first parameter. This informs RSX to pass status 
to any task connected to this one. You can also pick a specific 
task to receive status by placing the task ID here. 


Connecting It Up 

So how does this status word get to the connector task? 
Let’s walk through an example. Assume two tasks A and B. Task A 
executes a CNCT$ to task B. This causes RSX to create and queue 
an Offspring Control Block (OCB) to task B. 

Some t i me later, task B em its status. RSX fills the OCB 
with whatever task B specified via the EMST$, and returns the OCB 
to task A. Now the OCB is accessible to task A. Thus a simple 
method of intertask corrmun i cat i ons is completed. 

The connection between A and B, however, is lost. In order 
to do it again, task A must respecify the connection to task B 
(assuming that B is still hanging around, of course). One way of 
doing this is through the AST option in the CNCT$ directive. We 
can set up a piece of AST-driven code that reconnects to whatever 
task emits status to it. 

Enough talk, let's see some code. 


; Test program 

NAME: .RAD50 / FIDO/ 

START: MOV #TTABLE, R3 

MOV NAME, T$ID(R3) 

MOV NAME+2, T$ID+2(R3) 

CALL STASK 

. . . code continues . . . 


; Start Task Subroutine 

• Inputs: R3 - Points to task table entry 

• Outputs: RO - DSW status 

SNAME: .RAD50 /...SRV/ : Server taskname 

STASK: RPOI $S #SNAME. T$ID(R3) ; Start task up 

0 Q 5 1 $ ; Handle failure 

CNCTSS T$ID(R3),, #UPAST, TSSTAT(R3) ; Make connection 

1 $: MOV SDS/V, RO ; Get status 


Point at table 
Load taskname in 
table entry 
Start task up 
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RETURN 


Table Update AST Service Routine 
Inputs: R3 - Points to task table entry 

Outputs: Table updated 


UPAST: MOV R3, -(SP) 

MOV 2(SP), R3 

CNCTSS T$ID(R3),, #UPAST, 
MOV (SP)+, R3 

TST (SP)+ 

ASTXSS 


; Save R3 
; Point at entry 
T$STAT(R3) ; Reconnect task 
; Restore R3 
; Clear stack 

; Exit from AST 


"START’’ sets up a task name of ’’FIDO" in the first record of 
the Task Table. It also sets up R3 to point to that record. Now 
we can cal I STASK. 

At STASK the RPOI$ directive requests that a task be created 
from the prototype task at SNAME. In this case I call it 
"...SRV”. It should be installed prior to the call, otherwise 
the directive punts and STASK returns IE. I NS status in RO. I 
have elected to specify what task name "...SRV" clone will be 
cal led. 

(Note that this option exists only on M-Plus and Micro/RSX. 
If this option is omitted, the created task's name is based on 
which terminal it runs on; e.g. if on TT10:, the task is called 
SRVT10.) 

If all goes well with the RPOIS, we proceed to connect to 
task FIDO. Note how we do the CNCT$. We specify that an AST be 
queued when the connection is completed. We also set up 
TSSTAT(R3) to have FIDO's status written into. If all goes we I I , 
we should return to START with RO set to IE.SUC. We can now go 
on our merry way, confident that T$STAT(R3) contains the emitted 
status f rom FIDO. 

Whenever FIDO emits status, UPAST is called. It should find 
a pointer to the OCB at (SP). Because ASTs can occur at almost 
any point in the program, I save R3 for later use, and loaded it 
with the top of stack. R3 now points to the appropriate task 
table entry, in this case FIDO's. Then I execute a CNCT$ back to 
FIDO and set up the OCB at FIDO's record address. Next, I 
restore the state of things so I can exit from the AST. 

Notice that it doesn't matter which task emits status, 
because I can tell which task it is by looking at the OCB 
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address. (Which happens to also be the address of the 
appropriate server task table entry.) 


When Connecting is Not Enough 

Now that we have created what amounts to a reusable I ink 
with the EMSTS / CNCT$ pair, how can we improve on it? Let's try 
a few ideas I have used in my application. 


Running on Other Terminals 

In the above example, the prototype task "...SRV" is set up 
to be cloned a number of times. However, they are all running on 
the same terminal line. It woul d be nice if there were some way 
to also specify to the created task which terminal it should 
attach to. We can solve this problem by using one of those many 
parameters in the RPOIS that we previously ignored. 


Timestamping Status 

It is sometimes useful to know when was the last time a task 
emitted status. We can get this information by doing a GTIM$ in 
the AST. A logical place to put it would be in the appropriate 
task table entry. Then, the next time we check a task’s status, 
we can also find out how old this information is. 


Display Update Flag 

If the task table is used to provide information for a real 
time display, it is very helpful for the redisplay algorithm to 
have a quick way of knowing if something has "recently" changed 
in an entry. A good way to do this is by having the AST set 
something in the task table entry whenever it runs. The display 
routine can then update the corresponding screen field and clear 
the table entry. 


The RPOI$ directive allows us to specify which terminal the 
created task runs under. This is done with the "dname" and 
"unit" parameters, where "dname" is the ASCII device name of the 
terminal (typicaly "TT") and "unit” is the unit number. By using 
this parameter, the "...SRV" task can be written as if it were 
doing I/O to its standard TI:. There are three caveats, however. 

Note that in order to run a task on terminal other than 
one's own, the task executing the RPOI$ has to be Taskbuilt or, 
at the very least, installed privileged. In this case I specify 
a /PR:0 option in my TKB corrmand. 

A task can be created only on a physical device. For 
instance, you can use "TT" for a device name, but it doesn't 
really work for a pseudo device. 

If the task is running on a terminal that isn't logged in 
(most of the time in my application), there is no User Block for 
the task. This causes all sorts of problems if you use named 
directories since RSX tries to use your UIC as a default 
directory name. Just remember if you open any files to specify 
t he fuI I fi Iename . 


Passing a Corrmand Line 

With RPOI$ we can also pass a corrmand line on startup to the 
cloned task. Ws use the "bufadr" and "buflen" option, where 
"bufadr" is the address of a string to be passed to the task and 
"buflen" is the length in bytes. This corrmand line can be picked 
up by the target task by executing a GCML$ directive. This is 
useful for passing filenames and options to the server tasks. 


Use Your Imagination 

I have talked enough about what I have done. The best way 
to find out about what RSX can do for you is to sit down, code it 
up and try it out for yourself. I include here some code which 
improves on the previous example and includes some of the ideas 
just mentioned. Happy Hacking. 


Server 

Task Table Entry 

Format 


+-- 


-+ 



00 1 

1 

Status 

2 1 

TSStat 


02 1 

1 

Taskld (r50) 

4 1 

1 

T$ Id 


06 1 

TT n 

2 1 

TSTTn 


10 1 Corrmand 1 i ne 

i 

2 1 

1 

T $Qnd (Nu1 

Termi nated) 

12 1 Update Flag 

1 1 

TSUpdat 


13 1 

Time HMS 

3 1 

TSHTime, TSMTime. T$STime 

+— 


- + 



TSSTAT 

= 0 



; Task status 

T$ ID 

= TSSTAT + 

2 


; Task name in R50 

T$TTN 

= TSID+ 4 



; Terminal Number 

T$CMD 

= TSTTN + 2 



; Corrmand 1 i ne arg 

TSUPDAT = TSCMD + 2 



; Update byte 

T$T1 ME 

= TSUPDAT + 

1 


; T imestamp field 

TSHTIME = T$T1 ME 



; Hours byte 

TSMTIME = TSHTIME + 

1 


; Minutes byte 
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T$ST1 ME 

= TSMTIME + 1 

; Seconds byte 


T$LEN 

= T$ST1 ME + 1 

; Length of entry 


T $MAX 

= 64. 

; Maximum entries 

TTABLE: 

. BLKB 

<T$MAX * T$LEN > 

; Server task table 

SNAME: 

.RAD50 

/ . . .SRV/ 

; Server taskname 

; Start 

task 




1nput s: 

R3 - Points to task 

tab 1e entry 

; 

Outputs 

RO - DSW status 


STASK: 

MOV 

R3, RO 



ADD 

#T$CMD, RO 

; Get cmd line arg 


CLR 

R1 

; Zero line 1 ength 


Find length of string by looking for terminating null 

1$ : 

TSTB 

(RO) + 

; Is this a null? 


BEQ 

2$ 

; If so, exit 1oop 


INC 

R1 

; Bump string 1ngth 


BR 

1$ 

; And go look again 

‘ 

Request 

offspring task, pass OCB, and connect to offspring 

2$ : 

RPOI $ 

#SNAME.T$CMD(R3) 

,R1,,#"TT,T$TTN(R3),T$ID(R3) 


MOV 

SDSW, RO 

; Get status 


BCS 

3$ 

; On failure go die 


CNCTSS 

T$1D(R3),, #UPAST, TSSTAT(R3) ; Connect to task 


MOV 

$DSW, RO 

; Get status 


BCS 

3$ 

; On failure go die 

; 

Task started OK. Save status 

about it in the task table. 


MOV 

#5, TSSTAT(R3) 

; Set status of 5 


GT1 MSS 

#T1MBUF 

; Get system t ime 


MOVB 

SEC, TSSTIME(R3) 

; Set up start t ime 


MOVB 

MIN, TSMTIME(R3) 

; in table entry 


MOVB 

HOUR, T$HTIME(R3) 



CLRB 

T SUPDAT(R3) 

; Clear update flag 


3$: RETURN ; Return to caller 

; Table Update AST Service Routine 
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Inputs: R3 - Points to task table entry 

Outputs: None 



Erratum: Security of the RSX-11 Operating Systems 

Thomas R. Wyant I I I 
E. I. DuPont de Nemours & Co., Inc. 

Textile Fibers Department 
Richmond, VA 23261 


In my article on RSX security (see "Security of the RSX-11 
Operating Systems") in the June 1987 issue of The Multi-Tasker . 
the section on protecting the system console terminal recorrmended 
that the console be slaved at SYSVMR time via the following VMR 
command: 

VMR>SET /SLAVE=TTO: 

to ensure that the system comes up with the console terminal 
slaved and therefore unresponsive to attempted startup command 
file abor ts. 

This technique sounds good but, as it turns out, is a bum 
steer. It is defeated - deliberately! - by the SAV task. As 
part of its system startup processing, SAV selects a console 
terminal and explicitly marks it logged on, unslaved, and 
privileged. This negates the effects of the recommended VMR 
command. 

I know of no particular reason why the console terminal must 
be unslaved on startup. The code in SAV that unslaves the 
terminal is the statement: 
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BIC 


#U2.LOG!U2.SLV, U. CW2 (R3) 


HITCHHIKER'S GUIDE TO RSX 


at label FINDCO: in [12,10]SAVE.MAC on the SYSGEN kit. The 
obvious modification is to remove U2.SLV from the bit clear, 
producing the modified statement: 

BIC #U2.LOG, U.CW2(R3) 

then reassemble SAVE.MAC, library the new module, rebuild SAV, 
and re-VMR the system. 

I have NOT tried this; it may leave your system brain dead 
for some obscure reason. But if you're desperate to close that 
I i 11 I e wi ndow be tween the time the system comes alive and the 
time that STARTUP.CMD cranks up, here's a starting place. 


The Hitchhiker's Guide to RSX, Part II 

A-to-Z Base Product Marketing 
Digital Equipment Corporation 
Continental Boulevard, MK01-2/E25 
Merrimack, NH 03054 


Through the kind intervention of a Digital employee, the 
Multi-Tasker is pleased to present "The Hitchhiker's Guide to 
RSX''. This is probably the best overall coverage of the current 
RSX environment available. It is also a valuable reference for 
all application prograrrmers, not just business application 
deveIoper s. 


An Introduction to RSX for Business-Application Developers 


Revision 0.0 


Dis cI ai me r 

This is a preliminary version and is not quite one-hundred 
percent complete. Please send comments, questions, and 
recommendations -- on this document -- to A-to-Z Base Product 
Marketing, MK01-2/E25, Digital Equipment Corporation, Continental 
Boulevard, Merrimack, New Hampshire 03054. 

The information in this document is subject to change without 
notice and should not be construed as a commitment by Digital 
Equipment Corporation. Digital Equipment Corporation assumes no 
responsibility for any errors that may appear in this document. 

The software described in this document is furnished under a 
Iicense and may only be used or copied in accordance with the 
terms of such Iicense. 

No responsibility is assumed for the use or reliability of 
software on equipment that is not supplied by Digital Equipment 
Corporation or its affiliated companies. 


(C) 1986 by Digital Equipment Corporation 
All Rights Reserved. 

Printed in U.S.A. 


September, 1986 


This document is being serialized due to its length, 
is the second of three parts, covering chapters 5 through 8. 


This 


Copyrigh t 
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Hitchhiker's Guide to RSX 
DON'T PANIC 


Chapter 5 

Record Management Services (RMS) 


In the early days of RSX there was little in the way of 
facilities for file or record management. File ControI Services 
(FCS) offered routines to open and close files, and a Macro 
program could issue QIO requests directly to the disk driver. 
There was provision for sequential access to records and random 
access to disk blocks - but otherwise application deveIopers were 
left pretty much to themselves. The need for something more was 
apparent and eventually RMS-11 was developed. 


5.1 Introduction to RMS 

Record Management Services (RMS) is a Ianguage-independent 
set of file and record management routines which may be I inked 
into a user program to perform a variety of file and record 
related functions. Since the in-file format is determined by RMS 
and not by the host language processor, records within the files 
are also language independent, thereby providing a ready 
mechanism for exchange of data between applications. 

RMS has undergone several revisions since its inception, 
primarily to take advantage of more advanced hardware and 
operating system features. The first versions of RMS were a 
collection of object modules that had to be linked into, and 
carried about with, the task image. Modern versions take 
advantage of memory management hardware and CPU operating modes 
for improved speed and reduced disk space requirements and 
activity. 

The current version of RMS may be linked as a shared library 
which reduces disk requirements for task images and eliminates 
the overhead of disk overlays for the RMS routines. Another 
option is clustering the RMS library with the language OTS; this 
increases the amount of virtual address space available to the 
application. Lastly, it may be linked as a supervisor mode 
library on processors which support supervisor mode operation; 
this does all of the above and reduces the time required for 
context switching between libraries. For further details, see 
the chapter on linking. 

Full access to all RMS features is really only available 


through Macro. Each higher level language makes trade-offs in 
mapping traditional semantics of the language statements to 
facilities provided by RMS. Some languages allow the developer 
to specify the characteristics of a file being created with great 
precision; others do not. Some permit update of files opened 
for input; some do not. 

Some language statements may cause the run-time library to 
execute hidden RMS operations. The DIBOL WRITE statement, for 
instance, stores a record into both occupied and un-occupied 
cells, executing either an RMS PUT or UPDATE operation, as 
required. 

UtiIity programs are provided with RMS which provide for 
creating, converting, and re-organizing RMS files. These 
utilities can be used interactively or can be spawned from an 
application to perform their various functions. 


5.2 File Organizations 

RMS provides support for three major and two minor file 
organizations. The major types are sequential, relative and 
indexed. The minor types are "stream'' and "undefined"; these 
are not discussed further here. Types of access allowed to a 
file depend on its organization. 


5.2.1 Sequentia I 

Sequential files are the simplest format and, in some 
circumstances, offer the highest performance. A sequential file 
consists of a header and a number of data records. The file is 
loaded by writing a series of data records. Later, the records 
may be retrieved in the order in which they were written. 

When you create a sequential file you may specify that the 
file contains fixed or variable length records. Fixed length 
format offer the most efficient packing. Variable length format 
offers the greatest flexibility and is by far the more corrmon 
format . 

Sequential files are appropriate for serial writing or 
reading of records. Very high performance may be attained with 
languages which support the multiple buffering and deferred write 
features of RMS. 

There is no provision for deleting, replacing or updating 
records once a sequential file is created. Some languages permit 
opening a sequential file to append data to existing records. 
Sequential files with fixed length records do allow limited 
facilities for random access, but record interlocks are limited 
and this use is not encouraged. 


RSX-16 


RSX-17 



5.2.2 Relative 

Relative files consist of a file header, a prologue and data 
records. The header and prologue contain information about the 
file and the records. 

Data records are stored in groups known as "buckets". The 
size of the bucket is declared when the file is created, and each 
bucket is divided into as many record cells as will fit. Cells 
are all the same size and can hold the largest record. Maximum 
record size must be declared when the file is created. Data 
records within the cells may be fixed or variable length, but 
unused space in a cell containing a short record cannot be put to 
other uses. 

Once the file is created, the records may be loaded serially 
or randomly. There is a flag byte in each record cell which 
indicates whether a record is present, has never been stored or 
has been stored and then deleted. 

Records may be stored, retrieved, updated and deleted, 
randomly or sequentially. RMS automatically maintains a current 
record context which determines which record is selected for the 
next sequential operation. If a record is written to a cell 
beyond the end of the existing data, the file is automatically 
extended. New buckets are created and initialized by RMS, as 
required. 

Relative files represent a good compromise between 
convenience and efficiency. As long as buckets are densely 
populated data is stored with comparatively little overhead and 
access to any record in the file requires only a single I/O 
operation (not counting window turns). Interlocks are provided 
for files which have been opened for write access by one or more 
programs. Interlocks are maintained on a bucket basis. 


5.2.3 Indexed 

Indexed files offer the most flexibility to the programmer. 
You may access records directly or sequentially, by a primary key 
and any of up to 254 secondary keys. The keys may be located 
anywhere within the record, may be contiguous or segmented, and 
may be one of several data types. The index structure is 
dynamic, increasing in size and number of levels to accommodate 
new records as they are added to the file. 

Access time for all records is uniform whether the file is 
loaded in sequence by primary key, randomly across the file or in 
clusters. The number of I/O operations required to reach any 
record in the file is a minimum and is approximately equal to the 
number of levels in the index. 


In effect, RMS exchanges CPU time required to manage the 
(comparatively complex) index for more costly mechanical 
movements of the disk head. For small files there is little 
benefit to using this organization, but for files which contain 
tens of thousands of records the savings are substantial. There 
is a substantial amount of overhead carried with indexed files, 
both in terms of disk space and the code required to manage the 
file. 

Indexed files require the most attention to their design. 
There are a large number of design parameters associated with 
indexed files and unless values for these parameters are selected 
carefully, the file performance may prove disappointing. Due to 
the complexity of indexed files and the great variety of usage 
patterns it is impossible to provide defaults which are 
universally suitable and the burden of design is left to the 
deveIoper. 


5.2.3.1 St rueture 

An indexed file consists of a header, a prologue and two or 
more index levels for each key. The header describes the 
location of the file extents, and the prologue describes the 
structure of the records and the index levels. 

The lowest level of the primary index contains the data 
records themselves which are grouped together into buckets. 
Higher levels of the primary index contain copies of data record 
keys and pointers to the appropriate buckets at the next lower 
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structure. The structure of an alternate key index is the same 
as the primary key index except that, in place of user data, the 
lowest level contains Secondary Index Data Records (SIDRs). 
SIDRs contain alternate key values and pointers to data records 
in the primary index. 

There is only one copy of a data record in a file, but there 
may be several copies of the key field. Data records are 
collated in the buckets by primary key and the buckets are linked 
together so that sequential access can take place without any 
references to the index. 


5.2.3.2 PopuI ation 

A newly created file may be populated by writing records 
sequentially or randomly throughout the file. The index is 
dynamic, expanding both horizontally and vertically as required. 
When the initial allocation is exhausted RMS expands the file 
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automatically by allocating buckets as required. As buckets fill 
up they are split to make room for new records. 

Populating a file with an application program is not 
necessarily the best way to proceed, however. There are certain 
features of RMS pertaining to indexed files, such as Bucket Fill 
size, which are only available to Macro. In addition, secondary 
key indexes are often convoluted since even if the records are 
added to the file in order of ascending values for primary key, 
the values for the secondary key are unlikely to be in an optimal 
order. Both these problems can be overcome with the Indexed File 
Load (RMS IFL) utility. 


5.2.3.5 Interlocks 

RMS provides full interlock support on a bucket-wide basis. 
Each program which opens a file declares the operations that it 
wishes to perform and also the operations that it allows other 
programs. These declarations are often supplied by the language 
runtime system depending on the particular statement used and the 
default values may differ from one language to another. If the 
access declarations of all programs accessing a file are 
compatible, processing proceeds. Otherwise, the program opening 
the file with the incompatible access code receives a protection 
violation. 


5.2.3.3 Index Activity 

When a new record is added to the file, the primary index is 
scanned to find the proper bucket and the record is inserted 
according to its primary key value. If there is insufficient 
room to store the record, the bucket is split and half the 
records are moved to a newly created extension bucket. The next 
higher level index is updated to indicate the existence of the 
new bucket and the record is inserted. If the index bucket is 
filled, it too is split; and if the bucket being split is the 
root, a new index level is formed. 

If the file contains alternate keys, then each alternate key 
index must be searched until the lowest level is reached, a SIDR 
record added or updated, splitting the SIDR bucket if necessary, 
and so on. The amount of I/O required to store a new record or 
update an old one is a direct function of the number of keys. 


5.2.3.4 Storage Overhead 

The storage overhead in a bucket is a significant factor in 
indexed files and, unlike relative files, may increase over the 
life of a file. One of the features of RMS is that each data 
record in a file has a unique address, and, if the record is 
deleted, the address is never re-used. Because of this, deleted 
records leave behind residue which can be as little as two bytes 
(fixed length records, no duplicates for the primary key) or as 
much as the entire record (fixed length records, duplicates 
allowed for primary key). 

Similarly, if a record moves from its original location in a 
file when a bucket is split, a Record Reference Vector (RRV) is 
left in the original location. If you expect to be splitting 
buckets or deleting records frequently you must carefully 
consider the record type and key locations and the implications 
for bucket overhead. 


5.3 File Design 

The design and tuning of RMS files is an area of study unto 
itself. The number of possible usage patterns for files is large 
and it is not possible for RMS to anticipate the manner in which 
a particular dataset is accessed. There is no obvious limit to 
the amount of effort you may put into improving your files, but 
there is usually a point beyond which additional effort might be 
better expended elsewhere. You must decide for yourself when you 
have reached the point of diminishing returns. 

This section is not intended to be a comprehensive tutorial 
on file design but rather to point the way to those areas where 
small changes may have major impact on the performance of an 
application as a whole. See the RMS User Guide for further 
details about file usage and design. 


5.3.1 Which Files to Design 

Although it may seem obvious, you should limit your design 
efforts to those files which are most critical to the performance 
of your application. If a particular file is used only 
occasionally there is little benefit to spending a great deal of 
effort on optimizing its performance. Concentrate efforts on 
large files, files which have many simu Itaneous users, or files 
which have high levels of insertion and deletion activity. 


5.3.2 Selecting an Organization 

In general, the amount of processing and overhead necessary 
to manage a file increases with the flexibility of the available 
access methods. Sequential and relative file organizations are 
very fast and carry little or no overhead, but they do not 
provide all the access paths of the indexed organization. You 
almost always attain the highest performance by choosing the 
simplest file organization which can be made to provide the 
access features you require. 
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5.3.3 Corrmon Design Factors 

The design parameters of a file are set when the file is 
crea ted. The more complex the file organization, the more 
parameters there are to consider. There are some parameters, 
however, which are corrmon to al I file types. 


5.3.3.1 Allocation 

All files allow an initial allocation of disk blocks to be 
specified when the file is created. In the case of relative and 
indexed files, this allocation is mandatory since storage space 
must be provided for the file prolog. 

Allocating space for a file when it is created has two 
benefits. The allocation takes place all at one time and the 
disk blocks are likely to be located close together. The file 
can also be loaded without the interruption of extend operations. 

Unused space allocated to a file cannot be used for anything 
else. Once the file is fully populated, you may return any 
excess blocks to the operating system by truncating the file. If 
your language does not support the RMS truncate facility, you may 
spawn DCL with a SET FILE/TRUNCATE corrmand. 


5.3.3.2 Extend Quantity 

If a file is created wi th less than the amount of space 
required for storage of the data, you may wish to specify an 
extend quantity. This is the amount by which the size of the 
file is increased when additional space is needed. The extend 
operation is carried out automatically by RMS so your application 
may not be aware that it is happening. 

The default extend quantity for all files on a disk is set 
when the volume is initialized; this value may not be 
appropriate for a given file. If the extend quantity is too big 
you may waste space. If it is too small the file must be 
extended frequently, which means frequent interruptions in file 
processing, scattered file fragments and reduced performance of 
subsequent file processing. 

A corrmonly used rule of thumb is to specify an extend 
quantity derived from some unit of processing such as a day's 
worth of records. 


5.3.3.3 Contiguity 

The best single action you can take to assure optimal file 
performance is to make the file contiguous. 


To make a file contiguous you must allocate all the required 
disk blocks when the file is created, which may result in some 
wasted space until the file is filled. It may also require that 
you re-organize the disk with Backup (BRU) to gather the unused 
fragments into a larger, contiguous space. 


5.3.3.4 Carriage Control 

If the file is ever to be printed or otherwise output to a 
record I/O device (printer or terminal) you may wish to specify a 
carriage control attribute for the file. Carriage control 
determines the way in which RMS separates the records as they are 
being output. Instead of carrying the formatting information 
with each data record, RMS stores a single format setting in the 
file header and this setting is interpreted by the system 
ut i I ities when the file is printed. 

The default setting is CarriageReturn which means that as 
each record is output it is preceded by a line feed and followed 
by a carriage return. You may override this setting by 
specifying None. If you specify None you must store the 
formatting characters as data within your records, that is, you 
must explicitly include carriage return or line feed characters 
within your data records. Some languages have special file 
qualifiers which are used for this purpose. 


5.3.4 Designing Sequential Files 

Sequential file design is primari Iy a mat ter of allocation. 
Most such files are created wi th variable record lengths, and 
that's the end of it. You are allowed to specify that records 
may not span block boundaries but in most cases this practice is 
wasteful and not recorrmended. 

There is a special case situation involving fixed length 
records which you may wish to use. If you declare the records to 
be of fixed, defined length when you create the file you may use 
a I imi ted form of random access to the fi le. You may store and 
retrieve records either sequentially or randomly. Access to this 
facility depends on which language you are using, and there is no 
record interlock protection. 


5.3.5 Designing Relative Files 

Designing relative files is also comparatively simple. Like 
sequential you choose an allocation and extend size. Records may 
be of fixed or variable length, but the record cells allocated 
are of uniform size and large enough to contain the longest 
record. RMS keeps track of the byte count of variable length 
records so the application never sees anything except real data. 
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One additional design factor is determining the bucket size. 
A bucket is the logical structure within which records are 
grouped and the size you choose can affect the performance of the 
file. RMS reads and writes buckets in their entirety so that 
when you read a record from a file the entire bucket is loaded 
into a buffer in your program space. 

Bucket sizes are specified in blocks, 512 bytes. RMS fits 
as many record cells in a bucket as possible. Record cells are 
equal to the defined maximum record length plus one flag byte 
plus two length bytes if the records are variable length. 

Large buckets are good for access which is generally 
sequential or clustered. If your program reads a record and then 
reads an adjacent record which is in the same bucket, RMS fetches 
the record without re-reading the bucket, thus saving an I/O 
operation. 

Small buckets give better performance if the access patterns 
are random or if the file is shared between two or more programs. 
Interlocks are maintained by RMS on a bucketwide basis so that 
reading a record from a file with large buckets ties up more 
records than if smaller buckets are used. 

RMS also keeps a flag byte for each record cell in the 
bucket. This byte tells whether the cell has ever been used and 
whether it is presently occupied. RMS can therefore distinguish 
between records which have never been stored, have been stored, 
and have been deleted. 


5.3.6 Designing Indexed Files 

Designing indexed files can be a complex process. You must 
define key fields, decide on optimal bucket sizes, partition the 
file into areas and populate the file. Any or all of these 
decisions may affect the performance of the file. Here, more 
than anywhere else, you must consider each feature in light of 
its associated cost and use only those facilities which are 
reaI Iy necessary. 


5.3.6.1 Specifying Key Fields 

Wien you create an indexed file you must specify how many 
keys you intend to use and a number of parameters for each key. 
You must indicate how many segments each key has and where they 
are located, whether the key may be duplicated, what type of data 
it is, and an optional null value. 

Key placement within the record is not critical for static 
files. If, on the other hand, records are to be deleted, the 
primary key should be located at or near the beginning of the 


record to reduce the amount of residual overhead in the bucket. 

The length of the key is also important. Index buckets 
contain key values and bucket pointers. The shorter the key, the 
more index entries fit in a bucket; the index is shallower as a 
whole. Shallow index structures mean fast access. 

Keys may be string, integer or packed decimal fields. 
Whether or not you allow duplicate values depends on the 
application but you should be aware that allowing duplicates can 
slow down writing of records and increases the amount of overhead 
due to deleted records. 

Null values can be specified for alternate key fields. If a 
record is stored and an alternate key field contains only the 
null character then no entry is made for that record in the 
alternate key index. If many such records are stored the 
overhead of the alternate key index processing can be kept to a 
minimum. If at some later time the record is updated and a real 
key value is supplied, the alternate key index is updated 
accordingly. 


5.3.6.2 Sizing Buckets 

The same general rules govern bucket sizes in Indexed files 
that pertain to Relative files. If access is expected to be 
primarily sequential or clustered around certain key values, make 
the buckets large. If access is expected to be random or the 
file is heavily shared, make the buckets small. The memory 
penalty for large buckets is greater for Indexed files since RMS 
allocates two bucket-sized buffers when an Indexed file is 
opened. 

Furthermore, you should consider the relationship of bucket 
size and the number of levels in the index. The time required to 
process an index bucket (computation) is negligible compared to 
the time required to move to the next index level (I/O). 
Therefore, the time to access a record is directly proportional 
to the number of levels in the index. 

Larger buckets mean a shallower index and faster operations. 
You should set the bucket size to the smallest size (program size 
considerations) that results in an index with three or four 
levels including the data. Very large files may require five 
I eve Is total. 

You must anticipate the amount of activity overhead in the 
bucket due to splits and deleted records. If you expect the file 
to be static, that is, it is loaded once and then read many 
times, you need not allocate space for the overhead. If, on the 
other hand, you intend to insert and delete a lot of records you 
must allocate additional space. 
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Final I y, you may spec i f y a Bucket Fill S i ze when you create 
the file. This factor is the percentage of each bucket that is 
used if the Mass Load bit is turned on during the initial load of 
the file. This is of most benefit when records are added 
uniformly across the file. Leaving the extra space in each 
bucket reduces (but not necessarily eliminates) the number of 
bucket splits which occur and therefore the RRV overhead. There 
is still probably unused space in some buckets, however. 


5.3.6.3 Areas 

RMS Indexed files may be partitioned into Areas as part of 
the initial allocation. An Area is a portion of the file which 
is set aside for a specific purpose. Each index may have up to 
three areas allocated to it. Each Area may have its own 
allocation, extension size and bucket size. The primary 
advantage of this partitioning scheme is that logically related 
buckets are grouped closely together in a file and head movement 
while traversing an index tree or scanning sequentially through 
data buckets is minimized. 

In the simplest case a file could be divided into an Index 
and a Data area. When bucket splits occur, the extension buckets 
are allocated from the appropriate area. Without Areas, index 
buckets are scattered throughout the file in such a way that 
moving from one index level to another may require moving the 
disk head a considerable distance. 

Areas also a I I ow a certain amount of optimization. You may 
be able to improve performance by specifying a smaller index 
bucket if data records are very large and access is primarily 
random. Large index buckets should be used if records are small 
or access to the file is clustered. 


5.4 Tuning RMS Files 

File design is only one aspect of what makes an application 
mix go fast or slow. But it's a highly visible aspect, and is 
one with which developers feel most famiIiar and comfortable. 

It is often the case that poor file performance results from 
a lack of understanding that every feature of a system has an 
associated cost and, in some cases, the cost may not be obvious 
or may be described in such a way that its significance is not 
proper Iy marked. 

This section points out some of the more common areas in 
which unneeded features can burden an application. See the 
RMS-11 User Guide for more details. 


5.4.1 Avoid File Opens 

One of the most expensive things you can do with a file is 
to open it. RSX supports lots and lots of files in any given 
directory and developers who are moving over from CTS-300 may not 
be making effective use of the directory structure. 

Once you have a file open you should avoid closing it since 
the close usually means another open at some later time. There 
is more program space available on RSX than any other PDP-11. 
You may be able to keep files open on RSX that memory constraints 
caused you to close on other systems. 


5.4.2 Use the Simplest Possible File Structure 

If you use a multi-key index structure the file is 
necessarily larger and slower than if you use a single key. A 
single key file is more complex than a relative file and access 
to a record with a known key is slower. Sometimes developers 
discover that they can live without ISAM after all and the 
performance difference is considerable. 


5.4.3 Beware of Overloading Directories 

Directory searches are no different from scanning any other 
sequential file and records at the end take the longest to find. 
Keep your directories small and balanced for fast access. 

You should also realize that when you create a new file the 
system has to search through the entire directory to see if a 
file of the same name already exists. Consider re-using an old 
file in place of creating a new one. 


5.4.4 Pre-AIlocate the File 

If the file is to be static and the amount of data to be 
stored therein can be estimated then you may wish to allocate the 
entire file when it is created. This keeps fragmentation to a 
minimum and improve processing speed. Such allocations must be 
judged in light of total disk capacity and their affect on free 
space. 


5.4.5 Make Critical Files Contiguous 

The cost of locating the different parts of a file can 
represent up to 30% of the disk activity. Make your file 
contiguous. Failing that, make the extents of the file as large 
as possibIe. 
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If a file which is contiguous is extended then it is no 
longer strictly contiguous, although some of the benefits of the 
initial contiguity still pertain in that the initial allocation Avoid duplicate keys, if possible. Duplicate primary keys 

is a single large extent. If the file is further extended over increase the overhead of deleted records. Duplicate alternate 

t ime you may wish to periodically restore it to a contiguous keys can result in long chains of pointers in the SI DR records, 

state. You can do this from your application by spawning a 
COPY/CONTI GUOUS command. 


5.4.6 Substitute Code for Mechanical Movement 

Disk activity almost always involves some mechanical 
movement, often requiring tens of milliseconds to complete. It 
is often possible to replace disk operations with program code. 
If you are suffering a performance problem, try to determine 
whether you can simp I ify the file by doing a little more work i n 
your program. 


5.4.7 Distribute the Load 

Multiple disk spindles very often can provide more 
throughput than a single drive for a given total storage 
capacity. The disk head itself is subject to a number of demands 
in addition to data transfer such as directory manipulation and 
program overlays and consequently may become a significant 
bottleneck. Even though timesharing continues while the head is 
moved, all other disk I/O requests are delayed; and, since 
commercial systems depend heavily on I/O, this is a serious 
probI em. 

RSX supports overlapped seeks if multiple disk drives are 
available so that a number of disk requests can be processed 
simu ItaneousIy. 


5.4.8 Avoid Going Overboard 

Multiple keys are costly if records are being stored or 
updated in a file. The number of disk operations required to 
store a record is proportional to the number of keys. 

Very long keys consume extra storage and can increase the 
number of levels in an index by reducing the number of key 
entries in an index bucket. 

Keep the keys near the beginning of the record. For certain 
types of files, deleted records leave behind a fragment which 
includes the record from the beginning through the end of the 
primary key. 

Load the file in order of ascending key value. Doing 
otherwise causes more frequent bucket splits and a more complex 


RSX-28 


RSX-29 




Chapter 6 
RMS Utilities 


Most programming languages on RSX lack support for one or 
more RMS features. Moreover, there are a number of operations 
which should be carried out on a regular basis for creating and 
maintaining RMS files. Therefore, special utility programs have 
been provided which may be invoked interactively or may be 
spawned with a command file. 

What follows is a brief description of three of these 
utilities. For details about the operation and use of these 
programs see the RMS-11 Utilities Manual. 


6.1 RMSDES File Design Utility 

RMSDES is an interactive utility for designing and creating 
RMS files. You design a file by issuing commands to set, clear 
and display file attribute values in a file design buffer 
work space. 

Attributes are arranged in functional groups which pertain 
to the target system, file, record, key and areas for the file. 
You may enter or change the attributes in order from beginning to 
end, by section, or individually. You may enter the attribute 
values directly, load them from a description file or copy them 
from an existing data file. You may create a file directly or 
save the workspace in a description file for use at another time. 

When the attributes are arranged to your satisfaction you 
may create an empty file. RMSDES checks to see that all required 
values are present and performs sanity checks on the values. 


alternate key and then build the alternate key indexes. The 
resulting file is optimized for the fastest possible access along 
all index paths. 

RMSIFL has some limits. The index structures are created 
without the assistance of RMS which means that the output file 
must be empty at the beginning of the load. RMSIFL can handle no 
more than 20 keys per record and may be limited to bucket sizes 
of five blocks or less depending on the format of the record and 
the keys. 

These restrictions aside, RMSIFL is absolutely the fastest 
way to load a high performance indexed file. 


6.3 RMSCNV File Conversion Utility 

RMSCNV can read data records from any RMS file organization 
and load them into any other, either locally or over a network. 
RMSCNV uses the standard RMS facilities to read the data and 
build the output file. It is not subject to the same limitations 
as RMSIFL. 

RMSCNV can be used to append records from one file to 
another, re-establish contiguity and convert data from one file 
format to another. If the output file is to be sequential, 
RMSCNV can create it. Otherwise the file must be created before 
RMSCNV can be used. 

A number of switches are available (and may be required) 
which determine such operations as record truncation and padding, 
recognition of bucket fill size and mass insertion mode, block 
mode operation and so on. 

When used with Indexed file structures RMSCNV is not subject 
to any of the restrictions of RMSIFL but does not provide the 
same level of performance. 


6.2 RMSIFL Indexed File Load Utility 

RMSIFL reads records from any type of RMS file and loads 
them into an empty Indexed file. RMSIFL is superior to other 
loading methods in that it bypasses the standard RMS mechanism 
and exploits the underlying file structure to produce an output 
file quickly and with optimal packing of buckets. Use of RMSIFL 
is the most common way of honoring the Area Fill values specified 
for the indexed fiIe when it is created. 

RMSIFL operates in a number of phases. It optionally sorts 
the input records by primary key value before loading them into 
the indexed file. During the load it extracts any alternate key 
values and stores them in a temporary file. When the data 
records are completely loaded, RMSIFL sorts the values for each 
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Chapter 7 

RMS for CTS-300 Developers 


Since many conmercial users are migrating their applications 
from CTS-300, this section is set aside to point out some of the 
more corrmon I y encountered problems caused by the differences 
between DMS and RMS files. 


7.1 Record Locks 

The biggest single difference encountered by developers 
moving from CTS-300 to RSX is the way record interlocks are 
managed. 

CTS-300 (and VMS) were created with the record management 
facility tightly integrated with the operating system; 
therefore, it is possible to control access to shared files in 
such a fashion that potentially dangerous operations are avoided. 

The most corrmon such case is allowing one program, which has 
opened a file for input, to read a record or bucket which has 
been locked by a second program which has the file open for 
update. This is permitted on both CTS-300 and VMS such that read 
operations issued to a file opened for Input never encounter a 
record lock. There may, in fact, be delays in the read operation 
if the request occurs at a difficult time but these delays are 
temporary and are invisible to the application. 

RMS on RSX is more of a layered application than an integral 
part of the operating system. It is possible, therefore, that a 
program which has a file open for input might try to traverse an 
index tree which is being updated by another program and if this 
happened, the program issuing the read might crash. To prevent 
such an occurrence, any access to a file which has been opened 
for update or write operations is subject to record locks. 


7.2 Access Modes 

As explained earlier, DIBOL makes certain assumptions in 
mapping the various language statements to RMS facilities. One 
corrmon I y encountered example has to do with access modes declared 
when a file is opened. When a program calls upon RMS to open a 
file it must declare both the operations it intends to perform 
(Read, Write, Update, Delete) and also the operations it allows 
other programs to perform. RMS matches these access declarations 
with those of any other program which has the file open and only 
permits the latest program to proceed if the access codes are 
compatibIe. 


This has certain side effects. A corrmon example is the 
complaint that DIBOL on RSX is much slower than DIBOL on RT-11 or 
RSTS since it takes longer to read sequentially through a file. 
For some reason that is not clearly understood the sample file 
chosen for such experiments is always a relative file which 
results in an unexpected condition. 

When DIBOL opens an existing file for input it tells RMS 
that it wishes Read only access and, because of the traditions of 
CTS-300, it allows other programs write access. RMS interprets 
this as a hint that the data in the file may change (even though 
no other programs have the file open at that moment) and 
consequently re-reads the entire bucket each time the DIBOL 
program tries for the next record. 

If the DIBOL program were to open the file in Update mode, 
the bucket would be locked when the first read occurs, and 
subsequent reads take place directly from the bucket in memory. 
There would only be I/O when moving from one bucket to the next. 
The difference in processing speeds between input and update mode 
is directly proportional to the number of records in each bucket. 

That the open mode should affect the speed with which a 
program may scan a file is just one example of how "poor 
performance" may be due to a simple misunderstanding. 


7.3 Interchanging Sequential and Relative Files 

It is a corrmon practice on CTS-300 to create a file as 
sequential, fill it with records and then close the file and 
re-open it for random access. This is also possible with RMS 
except that the file must be created with a Relative structure. 
Whi Ie RMS permits limited random access to a sequentia I fiIe wi t h 
fixed length records, the use of Relative files offers more 
capabiIity and is the preferred method. 

There is one consideration in transporting such an 
application from CTS-300 to RSX or VMS. It is sometimes the case 
that such files begin with a header record wh ich is a different 
length than the transaction records. Since RMS relative files 
are allocated in record cells, each large enough to contain the 
largest possible record, it is wasteful to write a very large 
record followed by a number of smaller ones. It is much more 
efficient to write the header data into a number of smaller 
records and adjust the transaction record numbers accordingly. 


7.4 Extending Files 

RSX permits files to be extended regardless of the internal 
structure while CTS-300 does not. This means that you need not 
allocate all the space required for a file initially. 
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Performance suffers somewhat if the file is extended many times 
but you can overcome this by periodically using RMSCNV to restore 
the contiguity. 


7.5 Print Files 

It is corrmon practice on CTS-300 to write records in 
fragments using mixtures of VtfRITES and DISPLAY statements. This 
is done partly for coding convenience and partly due to the 
increased flexibility of formatting. This practice is possible 
because DMS files are really an unstructured stream of characters 
whereas RMS files (on VMS as well as RSX) are a series of 
records. 

Formatting of reports on RMS is provided through the Print 
Mode files (0:P) which use the NONE declaration for Carriage 
Control when the file is created. Each subsequent output 
operation, whether a WRITES, DISPLAY or FORMS creates an 
individual record and the application program is responsible for 
adding all the carriage control characters. While these files 
are somewhat lacking in storage efficiency, the prograrrmer has 
full control over the output format. 

A consideration when using such files is that attempts to 
re-read the file must be made with care. On CTS-300 it is 
possible to create a record in a file with a number of DISPLAY 
statements followed by a WRITES. On re-reading the file, all of 
the information is returned as though it had been written as a 
single record. With RMS this is not the case. Each field is 
stored as an individual record and is therefore returned as 
individual records in exactly the order with which they were 
wr i t ten. 


Chapter 8 
FI ow Con t roI 


Most small system corrmercial applications are broken down 
into a (possibly very large) number of program modules, each of 
which fits within the bounds of a limited hardware configuration 
and CPU architecture. Flow control is that aspect of application 
design which determines the manner in which these logic modules 
exchange information and control. 

One of the dimensions along which operating systems differ 
most widely is the variety and comparative efficiency of the flow 
control mechanisms. CTS-300 (RT-11) and RSTS are limited to 
program Chaining. VMS allows a primary program module to Chain 
to a secondary, spawn a secondary in a sub-process or, when the 
secondary module permits, call it as though it were a subroutine. 
RSX permits both chaining and spawning - each in a variety of 
flavors. Each of these mechanisms has its advantages and 
disadvantages. 

RSX originated in the scientific / industrial marketplace 
where realtime response is a top priority. The design point was 
to create a system in which a particular program module (Task) 
could be activated as quickly as possible upon the occurrence of 
some event. Consequently, the flow control architecture is more 
complex than the other systems, and it requires a bit of 
understanding before it can be used to greatest advantage. 


8.1 Concept of a Task 

The fundamental unit of execution on RSX is the TASK. 
System utilities are tasks. Compilers and editors are tasks. 
Application programs are tasks. 

Activation of a task is a two step process. 


8.1.1 Installing a Task 

Before RSX can do anything with a task it must be Installed. 
Installation is the process by which the location and 
characteristics of the executable module are made known to the 
system Executive. Once installed, a task is available for 
execution and remains so until it is removed. 

Each task on the system must be installed with a unique, six 
character name. During installation the Executive records the 
task’s location on disk (by File ID for very fast access), 
priority, the name of the partition in which the task executes. 
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and several other items which reduce to an absolute minimum the 
number of operations which remain before the task can actually 
begin to execute. 

Contrast this with other systems in which a RUN corrmand 
causes the Executive to begin looking through disk directories 
just trying to find the program image. 


8.1.2 Task Names 

Installed tasks are identified by name and therefore the 
name must be unique on the system. Multiple programs may have 
the same task name but only one of them may be installed at any 
time. The name of the task may be established when it is linked, 
when it is installed, or when it is requested and run. 

A special case of task naming is the "Prototype" name which 
consists of three periods followed by three alphabetic characters 
such as "...PIP". This is the mechanism by which multiple 
terminals can be executing independent copies of the same 
program. 

VWien a particular terminal invokes a task installed with a 
prototype name, the Executive creates a private copy of the task 
for the requesting terminal and gives it a unique task name by 
combining the prototype name and the terminal name. Thus, a copy 
of PIP running at terminal 11 becomes "PIPT11". The prototype 
task name is an important facility for systems where multiple 
copies of job streams may be executing simultaneously. 


8.2 Requesting an Installed Task 

Once a task is installed and brought to the absolute brink 
of execution, all that remains is for some entity on the system 
to request its execution. Some tasks are requested as a result 
of a corrmand typed at a keyboard. Others are requested via 
system directives issued by another program. There are a number 
of different mechanisms involved but the functionality of all of 
them falls into one of three categories. 


8.2.1 RUN a Task 

The simplest way to invoke a task is to RUN it. The RUN 
corrmand has four forms. 


8.2.1.1 Running an Installed Task 

If a task is already installed you may invoke it with the 
RUN corrmand and the task name: 


RUN taskname 


8.2.1.2 Running a Task from a File 

If a task is not installed you may invoke it directly f rom 
the task image file: 

RUN fiIespec 


This form of the RUN corrmand invokes a special facility 
known as Insta I I-Run-Remove. Before the task actually runs it is 
installed with your terminal name (e.g. "TT11") as the taskname. 
The task is then run and when it exits, it is removed. You may 
pass a corrmand to the task with the /COMMAND:"corrmand string" 
qua I ifie r . 


8.2.1.3 Running a System Utility 

You may invoke the system utiIities by preceding the task 
image filespec with a dollar sign: 

RUN $ RMSDES 

This tells RSX to look in the system library for the image file. 
You may pass a corrmand to the utility with the /COMMAND:"corrmand 
string" qua I i fie r . 

8.2.1.4 RUN as a Scheduling Corrmand 

The last form of RUN allows a privileged user to schedule 
the execution of an installed task for some future time: 

RUN/SCHEDULE : hh :rrm: ss taskname 


8.2.2 Chaining between Tasks 

The chain mechanism on RSX is the RPOI$ directive - Request 
and Pass Offspring Information. All the popular implementation 
languages provide support for this directive in one form or 
another. Check the User Guide for details. 

There are two options associated with the RPOI directive of 
which you should be aware. One option determines whether the 
program issuing the directive exits. The other determines 
whether RSX Parent-Offspring connections are passed to the target 
task. Unless there is a good reason to do otherwise, both these 
bits shouId be set. 


RSX-36 


RSX-37 



The directive itself may be used in two ways according to 
whether the offspring task has been installed. 


8.2.2.1 Indirect Chaining (to a non-insta I Ied task) 

You may chain to a non-installed task image file indirectly 
by forming the task image filespec into a pseudo RUN command and 
then RPOI to either MCR or DCL passing the string as a command. 
This is how DIBOL and BASIC implement the STOP filespec' and 
CHAIN 'filespec' statements. This form is the most fami liar to 
developers used to working with CTS-300 and RSTS, but it is also 
the least efficient. This is really a special case of the RUN 
filespec command and because of the number of intermediate tasks 
which must become involved it is the slowest form of chain. 


8.2.2.2 Direct Chaining (to an installed task) 

You may chain directly to an installed task by using the 
installed task name as the object of the RPOIS directive. DIBOL 
supports this form with the CHAINI subroutine. You may pass a 
command string to the offspring and the performance is much, much 
better than the indirect chain. 


8.2.2.3 Chaining to a Command File 

You may chain to a command file by issuing an RPOI$ to the 
Indirect Command File processor and passing the the name of the 
command file to be executed. The last action of the command file 
should be to invoke the next section of your application. 


8.2.3 Spawning an Offspring Task 

Developers who are moving from CTS-300 or RSTS may, at 
first, have difficulty understanding the significance of the 
Spawn facility but it is one of the principal reasons that RSX 
was chosen as the first operating system for A-to-Z. 

It is the foundation of the A-to-Z application integration 
architecture in which commonality of form and function is 
attained by spawning the appropriate module to perform an 
operation such as spawning Business Graphics to display some 
data. 

It also serves as the mechanism by which otherwise unrelated 
applications may be nested such that the operator may request an 
ongoing task to be suspended while another function is performed. 
That function may also be interrupted and so on. 

With or without A-to-Z, Spawn allows an application to 


invoke almost any facility on the syst em wi thout losing any 
context other than, possibly, the contents of the screen. You 
can spawn a system uti I ity wi th a command to create an ISAM file, 
for example, and wait for the exit status to determine the 
success or failure of the operation. You can spawn infrequently 
used sections of your own code as independent tasks to avoid 
having to bui Id them into the ma in I ine images. You can spawn the 
CL I tasks to execute commands as though they were being entered 
from the keyboard. The possibilities go on and on. 

Like Chain, Spawn has two forms depending on whether the 
offspring task is installed or not. 


8.2.3.1 Indirect Spawn (of a non-installed task) 

You can spawn a non-installed task indirectly by spawning 
your favorite command line interpreter with a 'RUN Taskname' 
command. You can include the /COMMANDcommand string" qualifier 
for the RUN command to pass a command string through to the task. 

You should also use the /STATUS:TASK qualifier as this 
assures that the exit status passed back to the parent task is 
that of the task and not the RUN command itself. Because it 
carries all the overhead of the RUN command entered from the 
keyboard, this is the slowest of the two forms of spawn. 


8.2.3.2 Direct Spawn (of an installed task) 

Direct Spawn of an installed task is the fastest way to 
invoke an external faciIity on RSX. You may pass the task a 
command string and you may wait for exit status. You can spawn 
more than one offspring task at a time if your implementation 
language interface to spawn permits. 

The designer of the parent task is responsible for deciding 
whether to wait for the offspring task to exit and for correctly 
interpreting any status which is returned. If task A spawns task 
B which in turns chains to task C passing all connections and 
task C exits, the status returned to A is that of C, not B. 


8.3 Parent-Offspring 

You may choose to create a library of spawnable tasks for 
your application. These tasks may perform infrequently used 
functions or they may serve to centralize certain functions as in 
the case of multiple front end tasks feeding transactions to a 
single (or multiple) background processor. The two most commonly 
used means of communication with the parent task are the command 
line buffer passed from the parent task to the offspring and the 
status code passed from the offspring back to the parent task. 
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8.3.1 Command Line 

RSX provides for passing a 255 byte command line to any 
offspring task. The offspring must retrieve this buffer through 
use of the GMCR$ directive. Access to this directive is 
available in the more popular implementation languages. This 
buffer may contain function codes, filenames or any other data in 
a format agreed upon by the parent and offspring task designers. 


8.3.2 Status Code 

RSX provides for a task which is Exiting to pass back a 
16-bit status code to the parent task. The directive is EXSTS 
and access to this directive is available in the more popular 
implementation languages. 

The low order three bits of this code are defined (by 
convention) to be the error code and severity level. The 
remaining bits may be used to communicate any other information 
in a format agreed upon by the designers of the parent and 
offspring tasks. 

A-to-Z has established a convention by which this 16 bit 
value is divided into fields, each with a particular meaning. 
You might consider adopting this convention. 


8.4.2 Global Event Flags 

RSX supports a second intertask communication mechanism 
which is specifically intended for synchronization of task 
execution. It is possible for a program which has access to 
system services to define and manipulate event flags on a task, 
group or system wide basis. 

Event flags are one bit registers which can be set, cleared 
or interrogated via system services. Typically one application 
sets a flag whenever data is available for processing by another. 
The wa iting app Meat ion clears the flag when all available data 
has been processed. 

Support for event flags is I imi ted or non-existent in some 
languages. It is mentioned here because it is the highest 
performance intertask signaling mechanism available on RSX. 


8.4 Intertask Communication 

RSX provides two principal mechanisms for communicating 
between tasks running on the system. 


8.4.1 Send/Receive 

Send and Receive can be used to pass blocks of information 
between cooperating tasks. The block can consist of up to 500 
bytes of information. If more data is to be passed it can be 
done with multiple blocks or by storing the informat ion in a file 
and passing the name of the file in a message. 

A second, more complex mechanism al lows passing of a memory 
common between two tasks. This feature is more complex than most 
applications require and the memory mapping requirements make its 
use in commercial applications uncommon. 

Support for Send Data and Send By Reference varies from one 
language to another. Some languages provide support through 
library subroutines while others allow access to the requisite 
system services. 
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RT-11 Minitasker 
August, 1987 


From the editor: 

Special thanks to all who contributed to this issue of the Minitasker. 

Rally Barnard has composed the SIG Tape from the Spring DECUS 
Symposium at Nashville. The contents of the tape, along with descriptions 
of the submissions is included here complete with cross-reference index. 

Nick Bourgeois has put together what may well be the first document 
describing in one place all of DEC'S magtape formats. If you've ever tried 
reading or writing a TYPE A magtape on a TYPE B operating system, you'll 
appreciate Nick's article. 

Yes, even after all these years, there are still bugs in RT-11. (Surprise!) 
Each month I'll compile any bugs I find or that have been reported to me. 
Mopreover, I'll try go get some official response from some appropriate 
person at Digital. With luck there'll always be a fix, a work-around or a 
"tsk=tsk." 


It is generally assumed that anything we publish in the Minitasker is open 
for public consumption. Copyrights, if any, remain with the original author 
of each submission. DECUS, the DECUS Newsletter, and Digital Equipment 
Corporation take no responsibility for accuracy, timeliness, or copyright 
infringements of any articles you find'in the Minitasker. (My shyster 
says I can't be blamed either!) 

Needless to say, I'm always looking for stuff to print. If you've got 
anything you think might be of interest to other RT-11 users, send it in. 
Camera ready copy is nice, but scribbling on a scratch-pad is acceptable. 

I can take machine readable articles and code on a variety of media - 
RX01, RX02, RX50, RL02 (!), 9-track tape (any format), and TK50 (any 
format). RT-11 files would be appreciated on machine readable media, 
but can, under duress, accomodate files produces by inferior operations 
systems. 

Send submissions to: 

John M. Crowell 

RT-11 Newsletter Editor 

c/o Multiware, Inc. 

2121-B Second St. Suite 107 
Davis, CA 95616 
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SPRING, 1987, RT SIG TAPE DIRECTORY 


Summary of the Spring, 1987, RT-11 SIG Tape 


SIG tape copy instructions .RT-3 

VIRTUL - Subdevice retriever for RSTS .RT-4 

DIRTWO - Annotated tape directories, part 2.RT-4 

WSHLST - RT-11 Wish List Survey.RT-4 

FONT - Downloadable VT-200 character font. RT-5 

SPELL - Spelling Checker with Dictionary.RT-5 

CALEND - Calendar Display Program . RT-5 

DFIND - Subdevice Directory Program . RT-5 

RDMF77 - Directory and Other Utilities . RT-6 

MAIL - On-Line Message Facility for TSX+ . RT-6 

TAPE - Tape Utilities . RT-7 

ACODES - On-Line Telephone Area Codes Retriever.RT-7 

TIMING - RT-11/TSX+ System Timing Studies. RT-8 

TSXLIB - Fortran-Callable TSX+ EMT's .RT-8 

DROIDS - The new Game Sensation .RT-9 

UCLPLS - User Command Language (UCL) Program .RT-9 

PM - RT-1 1 Monitor Prompt Handleroid .RT-9 

PLT - File-Oriented Plotting Utility for RT . RT-10 

FLXIND - IND Control Files for FLECS Processing .RT-10 

F77IND - IND Control Files for Fortran-77 Compilations . . RT-10 

BAKALL - IND Control File to Automate Backups.RT-11 

THESIS - RUNOFF Macros for Formatting a Thesis .RT-12 

GKS - RT-1 1 Implementation of GKS Plotting Standard . . . RT-13 

INDFIL - IND Control Files for Subdevices.RT-13 

DIAL - Terminal Emulator Front End . RT-14 

KERMIT - File transfer protocol for PDP-11 s .RT-15 

Tape Distribution Information . RT-15 

Cross-Reference Index .RT-16 
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******************************************************************** 

DECUS Symposium RT-11 SIG Tape 

Spring, 1987 
Nashville, TN 

Annotated Directory 

******************************************************************** 

IMPORTANT 
NEW INFORMATION 

Subdevice files on this tape are now allowed to be as large as 
800 blocks (the size of a RX-50). (For the sake of convenience, 
the data files for the TIMING submission are in slightly larger 
subdevices). This improves efficiency. If you need to copy a 
file larger than 494 blocks to a RX01, use the COPY/MULTI VOLUME 
command. 

Read the file TAPCOP.TXT if you need SIG Tape copy instructions 
or information for retrieving files using RT-11 version 4, or 
RSTS. 


If you have any comments, corrections or contentions with any of 
the submissions on this tape, please discuss them directly with 
the authors. 


******************************************* 

* Please look at the WSHLST submission * 

* and respond to it! * 

******************************************* 


VIRTUL - Subdevice retriever for RSTS. 

E.F.Beadel, Jr., Manager 

CAUSE Instructional Computer Center 

SUNY at Oswego 

Oswego, NY 13126 

(313)341-3055 

This program allows RSTS/E users to break down the subdevice 
files from this tape after they have been copied to disk. It has 
been modified by David Smith, Galileo Computer Center, to remove 
a few bugs and to be able to read multi-segment directories. See 
TAPCOP.TXT for details. 

VIRTUL.BAS 1 File, 43 Blocks 
************************************************************ 

DIRTWO - Annotated tape directories, part 2. 

R. W. Barnard 

Sandia National Laboratories 
Minicomputer Software Division 7523 
P. 0. Box 5800 
Albuquerque, NM 87185 
(505)844-5115 

DIRTWO contains annotated directories of the DECUS Symposia 
RT-1 1 tapes from the Fall of 1981 through the Fall of 1986. The 
most recent SIG tape on which the directory of previous tapes is 
located is the Spring, 1985, and is called DIR1.DSK. 

DIRTWO.DSK 11 Files, 558 Blocks 

v*********************************************************** t 

WSHLST - RT-11 Wish List Survey. 

Robert Walraven 
Multiware, Inc. 

2 121 -B Second Street, Suite 107 
Davis, CA 95616 
(916)756-3291 

The RT-11 SIG is very interested in your responses to the 
wish list items contained in WSHLST. From your responses will be 
determined some of the new features of RT-11. Please take the 
time to review and respond to this submission. 


WSHLST.DSK 2 Files, 101 Blocks 



RDMF77 - Directory and Other Utilities. 


FONT - Downloadable VT-200 character font. 

SPELL - Spelling-Checker with Dictionary. 

CALEND - Calendar Display Program. 

Harold Z. Bencowitz 
810 Hospital Drive, Suite 240 
Beaumont, Texas 77701 
(409)835-3770 

FONT is a program written in Whitesmith’s C to allow one to 
easily create or alter downloadable fonts/character sets for 
VT200 series terminals. It can be used to edit a previous 
character set (stored as a disk file). One character at a time is 
edited while each pixel change is observed both at the normal 
size and double high/double wide. 

CALEND is a program written in Whitesmith's C to display the 
calender for a selected month. It will accept any month and year 
from 1583 - 32000. 

SPELL is a spelling checker written in Whitesmith's C. Words 
in the input file are compared to one or more dictionaries (files of 
alphabetized words) and an alphabetized list of the unmatched 
words is sent to the output file(s). The output list can include each 
word as many times as it is used or optionally only once. 

The file README.lst and the common files are contained in 
the VTFONT.DSK file. 

VTFONT.DSK 12 Files, 406 Blocks 
CALEND.DSK 3 Files, 50 Blocks 

SPELLR.DSK 6 Files, 475 Blocks 
************************************************************ 

DFIND - Subdevice Directory Program. 

Carl Lowenstein 
U. C. San Diego 
Marine Physical Lab, P-004 
La Jolla, CA 92093 

DFIND is a utility for searching through an RT-11 structured 
file system and the subdevices on it. Upon a successful match, 
the filename, size, and date are printed, as well as the file 
path (sequence of subdevices) leading up to it. 

DFIND0.DSK 7 Files, 122 Blocks 

************************************************************************ 


Walt Shpuntoff 

Institute for Resource Management, Inc. 

PO Box 869 
Arnold, MD 21012 
(301)757-6503 

This submission provides Fortran-77 interface subroutines 
that make it possible to read and write RDM database file records 
from an F77 application. The routines allow you to retrieve and 
write back out active records, convert dates to and from RDM 
format, and open and close RDM files. 

(RDM is a trademark of Interactive Technology, Inc.) 

RDMF77.DSK 18 Files, 154 Blocks 
********************************************************************* 

MAIL - On-Line Message Facility for TSX+. 

TAPE - Tape Utilities. 

Mike Marak, David Gaudine, Dr. S. J. Kubina 

EMC Lab, Room AD-532 

Loyola Campus 

Concordia University 

7141 Sherbrooke St. W. 

Montreal, Que. H4B 1R6 
Canada 

(514)848-3118 

MAIL is on online message sending system which allows users 
to send messages to other users and to read messages that have 
been sent to them. It is designed to run under TSX-PLUS. Mail 
can be run from a logon command file or as a keyboard command. 
The system consists of a common file that contains the list of 
current users and any messages for each user, a maintenance 
program that allows the postmaster to maintain the mail file, and 
a MAIL utility which allows users to read, delete, or send mail 
to another user. A system command file is used to tell the 
utility program if MAIL has been invoked from LOGON or by the 
user. 
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The programs TAPE%% are utilities to back up specific disk 
devices to magtape. TAPERK backs up 4800-block devices (RK05's), 
TAPEDL does RL02‘s, and TAPEDU does RD52's. Once a disk is 
backed up by these utilities it can easily be restored; in 
addition, the directory name can also be changed. Individual 
files from the backup can be retreived. These programs run under 
TSX+; they are too big to run under RT, but may work using 
VBGEXE. This submission also includes ANSIR and ANSIW, for 
reading and writing unlabelled ANSI magnetic tapes, and T20IBM, 
for reading EBCIDIC IBM tapes. 

TAPUTL.DSK 10 Files, 500 Blocks 
MAILUT.DSK 10 Files, 289 Blocks 

I*********************************************************************** 

ACODES - On-Line Telephone Area Codes Retriever. 

Bill Leroy 

The Software House, Inc. 

P. 0. Box 52661 
Atlanta, GA 30355 
(404)231-1484 

ACODES.TXT is a list of North American telephone area codes 
and major cities in those area codes. It also lists FTS on-net 
to off-net phone numbers. The file is accessed by means of the 
GREP program. Combined with a UCL symbol, you can retrieve area 
codes by state or city, or retrieve all the area codes in a 
particular state. 

Editor's Note: In typical UNIX/C fashion, the documentation 
for GREP is so abysmal that most people will not be able to 
decipher it. To implement an on-line retrieval of area codes, 
define the following UCL+ symbol: 

ACODES == r GREPX-f SY;ACODES.TXT 

You can then type 

aco 505 to get the information about area code 505, or 
aco texas to find out all the area codes in Texas, etc. 

ACODES.DSK 4 Files, 49 Blocks 

**4^****************************************************************fc** 


TIMING - RT-11/TSX+ System Timing Studies. 

Jim Crapuchettes 
Omnex Corporation 
2483 Old Middlefield Way 
Mountain View, CA 94043 

This submission contains the data files generated for RT-11/ 
TSX-Plus System Timing tests that were described in the session 
presented at the Spring, 1987, DECUS Symposium in Nashville TN. 

It also includes files describing the test procedure and some data 
reduction programs. These tests are to determine the EMT-level 
responses of RT-11 and TSX+, and include tests on 11/23 and 11/73 
processors, RT-11 SJ, FB and XM monitors and TSX+. 

TIMING.DSK 10 Files, 94 Blocks 
TMNG01.DAT 21 Files, 861 Blocks 
TMNG02.DAT 23 Files, 943 Blocks 
TMNG03.DAT 23 Files, 943 Blocks 
TMNG04.DAT 23 Files, 943 Blocks 
TMNG05.DAT 23 Files, 943 Blocks 
TMNG06.DAT 23 Files, 943 Blocks 
TMNG07.DAT 23 Files, 943 Blocks 
TMNG08.DAT 23 Files, 943 Blocks 
TMNG09.DAT 23 Files, 943 Blocks 
TMNG10.DAT 23 Files, 943 Blocks 
TMNG1 l.DAT 3 Files, 123 Blocks 

**************************M****************************t**** 

TSXLIB - Fortran-Callable TSX+ EMT's. 

N. A. Bourgeois, Jr. 

NAB Software Services, Inc. 

P. 0. Box 20009 
Albuquerque, NM 87154 

TSXLIB is a library of FORTRAN callable routines that implement 
the TSX-Plus system services which are unique to TSX-Plus. The 
library has been updated to include all TSX-Plus unique services 
through TSX-Plus V6.2. The TSXLIB distribution kit includes the 
MACRO-11 source modules for all the routines, a user's manual in 
machine readable form, an indirect command file to build the 
library, and the implemented library. 

TSXLB1.DSK 4 Files, 500 Blocks 
TSXLB2.DSK 12 Files, 448 Blocks 

*********************************************************************** 
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DROIDS - The new Game Sensation. 

Robert Walraven 
Multiware, Inc. 

2121 -B Second Street, Suite 107 
Davis, CA 95616 
(916)756-3291 

DROIDS is a game which pits your (or your kid's) skills 
against a planetfull of droids bent on your destruction. Future 
Symposia will include sessions on current DROIDS strategy and 
reports on the current champion status as recorded in DROIDS.SCR. 

Note added in proof: 

It is necessary to SET TERM NOCRLF for proper operation of 
DROIDS. 

DROIDS.DSK 4 Files, 92 Blocks 

*********************************************************************** 

UCLPLS - User Command Language (UCL) Program. 

PM - RT-11 Monitor Prompt Handleroid. 

William K. Walker 
Monsanto Research Corp. 

P. 0. Box 32 
MS A-152 

Miamisburg, OH 45342 
(513)865-3557 

UCL+ is upward-compatible with the UCL distributed with 
RT-11, Version 5.IB and later. The version submitted to this tape 
is V07.55 b, an update from all previous versions. This version 
of UCL+ includes a fix of an obscure bug. Otherwise it still 
includes all the extra features which make it so useful. 

PM is a RT-11 "handleroid" which permits user-defined KMON 
prompts (replacing the "."). Read the documentation before using 
it! 

UCLPLS.DSK 22 Files, 698 Blocks 

PMHDLR.DSK 4 Files, 37 Blocks 
************************************************************ 


PLT - File-Oriented Plotting Utility for RT. 

Peter E. Bodmer 

Boys' Town National Institute 

555 N. 30th 

Omaha, NE 68131 

(402)449-6711 

PLT is a RT-11 program that translates a user-specified text file 
consisting of plotting commands into Tektronix 4662 language. The 
set of Tektronix 4662 language commands are placed into an output 
file which can then be sent directly to a Retro-Graphic terminal. The 
output files or .TEK files can also be sent to a DataSouth Line Printer 
or to a HP 7475A pen plotter. The typical input to PLT is a standard 
ASCII text file that contains plotting parameters, keywords, data, and 
comments. The user may obtain data from another program, or may 
call another text file as a virtual subroutine, or have PLT request 
parameter/data entry during execution. PLT files may be created by 
entering the text into a file manually, using an editing program, or by 
writing and executing a program that creates, writes into, and closes 
the file. 

RTPLTl.DSK 11 Files, 540 Blocks 
RTPLT2.DSK 64 Files, 600 Blocks 

************************************************************************ 

FLXIND - IND Control Files for FLECS Processing. 

F77IND - IND Control Files for Fortran-77 Compilations. 

Edward L. Hendrickson 
258K Metals Development 
Ames Laboratory ISU/USDOE 
Ames, IA 5001 1 
(515)294-3590 

FLECS.IND is an IND command file that automates the use of FLECS. 
Without FLECS.IND the user must remember the FLECS command 
string syntax, then wait for the source to be translated to Fortran, 
then compile the .FTX (Fortran) code into object code using the correct 
Fortran command string syntax. With FLECS.IND the user types one 
command string and the entire process is completed transparently. 

F77.IND is an IND command procedure that simulates all of the 
FORTRAN switches available. F77.IND can either be used as a stand 
alone command procedure or as an /F77 switch with FLECS.IND file. 
This also inlcudes a resubmission of the INDEX program. 
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Compiler switches may go either before or after the file 
name; there is an on-line display of the F77.IND help 
documentation. 

If F77.IND is used as without FLECS, then there are 17 
switches available: 

/A*ssemblylist[=<filespec>] 

-- Same as /L but with a listing of assembly code. 
/B*ounds — Checks for array references out of bounds. 
/C*ontinue=n -- Sets the maximum number of continuation lines. 
/D*ebug — Lines with D in column 1 are compiled. 
/E*xtendlines — Compiler interprets source text in cols 73-132 
/F*uiitrace — Generates very detailed traceback (see Trace) 
/L*ist[=<filespec>] 

-- Creates a list file with source listing, program 
section summary, and storage map. 

/Nos*wap -- Inhibits swapping of USR over the program. 
/Noo*bject — Suppresses creation of an object file. 
/0*bject=<filespec> 

— Change the default device, name, and/or extension 
of the object file. 

/R*ecordlength=n 

— Specifies the maximum record length (in bytes) 
for run time I/O (4 < n < 4095). 

/Statistics — Produces a stat report. 

/T*race — Generates extra code for OTS error traceback. 
/U*nits=n — Sets the number of logical units available. 
/Warnings — Enables printing of W-class warning diagnostics. 
/Wi*demap — Produces a 132-column map listing. 
/Wo*rkfiie=n — Sets the length of the workfile in disk blocks. 

FLXIND.DSK 10 Files, 622 Blocks 
F77IND.DSK 4 Files, 76 Blocks 

ft*********************************************************** 

BAKALL - IND Control File to Automate Backups. 


Edward L. Hendrickson 
258K Metals Development 
Ames Laboratory ISU/USDOE 
Ames, IA 5001 1 
(515)294-3590 


Paul Lustgraaf 
32 Carver Hail 
Iowa State University 
Ames, IA 500 1 1 
(515)294-1832 


BAKALL.IND is an IND command file that automates the backup 
process. It backs up a complete device to magnetic tape using the 
BACKUP/DEVICE command. The code currently keeps track of 5 
complete backup tape sets and 2 devices, DUO and DU1. BAKALL 
will open a LOG file and record all necessary data needed to 
document each individual tape. 

BUPRES is a FORTRAN IV program which reads individual files 
from a magnetic tape created by the RT-11 version 5 BACKUP 
command. The program has been modified since it was originally 
submitted to the tape. The DIR function has been changed so that 
it is compatible with the output from DIR/COL: 1 which allows you 
to look for differences without restoring the whole volume. The 
program now works directly with the magtape handler instead of 
using EXTMT. 

BAKALL.DSK 5 Files, 46 Blocks 
************************************************************ 

THESIS - RUNOFF Macros for Formatting a Thesis. 

Mark M. Mehl 

Department of Biomedical Eng 
IOWA STATE UNIVERSITY (ISU) 

Ames, IA 5001 1 

ISU RNOTHESIS is a collection of Bonner Lab RUNOFF macro commands 
that can be used to format a thesis. There are commands for 
generating floating tables and figures, in-line equation lists, 
footnotes, points, quotations, and a bibliography. Although 
RNOTHESIS is being used to format theses according to the Iowa 
State University thesis office requirements, its macros can be 
adjusted to support any large document layout. 

THESIS.DSK 15 Files, 427 Blocks 
************************************************************ 
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GKS - RT-11 Implementation of GKS Plotting Standard. 

James V. Flatten 
2581 Metals Development 
Ames Laboratory, ISU/DOE 
Ames, IA 5001 1 

This document describes an implementation of the Graphical 
Kernel System (GKS) for the RT-11 operating system running on a 
PDP-11 computer. This implementation is the lowest level of GKS, 
which was chosen to keep the graphical subroutine library small 
and efficient for applications running under RT-11. Three device 
drivers are provided for the HP7475 6 pen plotter, the Tektronix 
4107 color terminal and the Visual 550 terminal. 

GKS020.DSK 20 Files, 560 Blocks 

*********************************y********************************** 

INDFIL - IND Control Files for Manipulating Subdevices. 

R. W. Barnard 

Sandia National Laboratories 
Division 7523 
P. 0. Box 5800 
Albuquerque, NM 87185 
(505)844-5115 

The following IND control files have been extensively 
updated since they were last included on the SIG Tape. 

DOWN and UP can be used to conveniently move among subdevices. 
Using these facilities, you can have the equivalent of 
subdirectories on a VAX. DOWN will mount a subdevice file using 
the Logical Disk handler and assign either the default or a 
user-selected logical name to that device. If the device is not 
specified, DOWN will search through a predetermined list of 
devices to look for the file. UP moves "up" one level of 
subdevice nesting. DOWN uses PARSE, an IND procedure which is a 
comprehensive filespec parser. It also uses the program READLD 
to determine the LD units currently associated with files, and 
the corresponding logical assignments. HOME is a special case of 
UP which is implemented with a UCL+ symbol. OVER is a UCL+ 
symbol to move from one subdevice assignment to another. CUR is 
a UCL+ symbol to report what your current subdevice assignment 
is. The file UCL.UCJ provides UCL+ symbol definitions for DOWN, 

UP, HOME, OVER and CUR. 


NEWLD can be used to easily create a new file to be used as a 
subdevice. NEWLD accepts the parameters file name, size, logical 
name, number of directory segments, and whether the file is to be 
"net" or "gross" size. Defaults can be used for many of the 
parameters. File sizes can be specified in either of two ways - 
as a numerical value or as a disk type (RX01, RX02, RX50, RL01, 
etc). 

INCBUP does incremental backups (i.e., backs up only files 
created since the previous backup) and catalogs the directories 
of the backed-up files for rapid retrieval. Backups can be done 
from any size or type of disk (including LD’s) to any other disk. 
The backup target device can be a subdevice file on a larger 
disk, thereby permitting several "backup sets" to be on one 
physical disk. The volumes on which the backed-up files are 
copied are identified by a unique name and extension as the 
"backup set identifier". A printed directory of the backed-up 
files is also made. Backups of several devices can be done in 
one INCBUP "session". You have the option to use the same 
parameters for subsequent backups. File cataloging is done with 
the DSKLIB program. This package has been included on previous 
tapes, such as the Fall, 1986 RT SIG tape. 

INDFIL.DSK 18 Files, 258 Blocks 

******************************************************************** 

DIAL - Terminal Emulator Front End. 

Maarten van Swaay 
Kansas State University 
Department of Computer Science 
Nichols Hall, CS 
Manhattan, KS 66506 

DIAL is a package that can be used in front of terminal 
emulators. DIAL is designed to retrieve its input from a command 
file, which can direct it to initialize a HAYES-type modem and to 
penetrate through a layer of data switches, transport services, 
logon dialogs, etc. 

DIALER.DSK 3 Files, 38 Blocks 
***************************************************************** 
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KERMIT - File transfer protocol for PDP-ll's. 


Cross-Reference Index 


Brian Nelson 

Computer Services, University of Toledo 
2801 West Bancroft 
Toledo, OH 43606 
(419)537-2841 


The Kermit files for RT-11 which are included on this tape have 
been taken from the Fail, 1986, SIG Tape. This is not a new submission. 


This is release 2.44 of Kermit-11. Major changes from previous 
versions include long packet support, BREAK and DTR control for RT, 
a DIAL command, and other small fix-ups. It runs on all PDP-11 
operating systems. For RT-11, you must have multiterminal support 
if you are using version 4.0. For RT version 5.1 and later, multi¬ 
terminal support is not needed if you use the XL or XC handier. 

For TSX+, you must use the CL facility for outgoing lines. See the files 
K11AAA.AAA, and K11INS.DOC for more information. Edit history is 
given in the file K11CMD.MAC. 


KERDC1.DSK 9 Files, 355 Blocks (Documentation Files) 
KERDC2.DSK 5 Files, 428 Blocks (Documentation Files) 
KERCM1.DSK 12 Files, 486 Blocks (Common Files) 
KERCM2.DSK 6 Files, 486 Blocks (Common Files) 
KERCM3.DSK 17 Files, 222 Blocks (Common Files) 
KERRT1.DSK 18 Files, 380 Blocks (RT Files) 

KERRT2.DSK 2 Files, 390 Blocks (RT Files) 




** 


The Spring, 1987, RT SIG tape contains 46 Files, 20417 Blocks. 
It was prepared by: R. W. Barnard 

Sandia National Laboratories 
Division 7523 
P. 0. Box 5800 
Albuquerque, NM 87185 

DCS - BARNARD 


It is available from the following sources: 

DECUS LIBRARY 


DECUS NLO TAPE TREE 
c/o Robert N. Perry 
Tektronix, Inc. 

PO Box 500 
MS: 19-333 
Beaverton, OR 97077 
(503)527-5410 


DECUS Program Library 
BP02 

249 Northboro Road 
Marlboro, MA 01752 


DCS - PERRY 


ACODES . RT-7 

ANSIR - Read unlabeiled ANSI tape.. RT-7 

ANSIW - Write unlabeiled ANSI tape . RT-7 

Archiving system . RT-ll.RT-14 

Area Codes .RT-7 

Backup utilities .RT-7, RT-14 

BAKALL . RT-11 

Barnard, R. W. RT-4, RT-13, RT-15 

Beadel, E. F., Jr.RT-4 

Bencowitz, H.RT-5 

Bodmer, P. E.RT-10 

Bonner Lab RUNOFF macros . RT-12 

Bourgeois, N. A.RT-8 

BUPRES .RT-12 

CALEND . RT-5 

Calendar Display .RT-5 

Comparison of speed of 11/73 and 11/23 .RT-8 

Comparison of speeds of SJ, XM, TSX+ .RT-8 

Crapuchettes, J. RT-8 

Database interface . RT-6 

DataSouth printer plotting routines. RT-10 

DECUS library.RT-15 

Determine which LD's are mounted . RT-13 

DFIND. RT-5 

DIA L . RT-14 

DIR1.DSK .RT-4 

Directory of older SIG tapes . RT-4 

Directory of recent SIG tapes.RT-4 

Disk librarian .RT-13 

DOWN - IND Control File.RT-13 

DROIDS . RT-9 

EMT execution speeds . RT-8 


RT-15 


RT-16 



































F77.IND - Compiler file for Fortran-77 .RT-10 

File search utility. RT-5 

Flatten, J. V.RT-13 

FLX.IND - Compiler file for FLECS. RT-10 

FONT . RT-5 

Fonts for VT-200 . RT-5 

Formatting commands for a thesis. RT-12 

Fortran-77 compiler control file . RT-10 

Fortran-77 Interface to RDM.RT-6 

FTS phone numbers.RT-7 

Games. RT-9 

Gaudine, D. RT-6 

GKS.RT-13 

Handler. RT-9 

Hendrickson, E. L. RT-10, RT-11 

How to get the SIG Tape.RT-15 

HP-7475A plotter routines. RT-10,RT-13 

INCBUP - IND Control File. RT-13 

Incremental backup . RT-13 

IND control files. RT-10 thru RT-14 

INDEX - cross-reference program. RT-10 

KERMIT File transfer protocol. RT-15 

Kermit, Version 2.44 . RT-15 

Kubina, S. J.RT-6 

Leroy, W.RT-7 

Lowenstein, C. RT-5 

Lustgraaf, P. RT-11 

Magtape backup for specific-sized devices.RT-6 

Marak, M. P.RT-6 

Mehl, M. RT-12 

Modem control package. RT-14 

Multiware, Inc.RT-4, RT-9 

NAB Software Services, Inc.RT-8 

Nelson, Brian.RT-15 

Omnex, Inc.RT-8 

On-line Area Code Retrieval.RT-7 


PARSE - IND Control File . RT-13 

Perry, Robert. RT-15 

Plotting routine .RT-10, RT-13 

PLT.RT-10 

PM.SYS . RT-9 

Prompt "handler" . RT-9 

RDMF77 - RDM Interface .RT-6 

Read individual files from BUP tape.RT-12 

READLD - Determine which LD s are mounted. RT-13 

Redefine the RT-11 prompt symbol . RT-9 

RSTS program for reading subdevices. RT-4 

RT-11 Wish list survey . RT-4 

RT/TSX Kermit. RT-15 

RUNOFF .RT-12 

Search a volume and subdevices .RT-5 

Shpuntoff, W. RT-6 

SIG Tape Directory, Fall, 81 - 86 . RT-4 

SIG Tape Directory, Spring, 82 - 86 .RT-4 

SPELL.RT-5 

Spelling Checker . RT-5 

Sub device directory utility. RT-5 

Subdevice file utilities . . RT-13, RT-14 

T20IBM - Read unlabelled EBCIDIC tape.RT-7 

TAPCOP.TXT .RT-3, RT-4 

TAPEDL - Back up a RL02 device .RT-7 

TAPEDU - Back up a RD52 device . RT-7 

TAPERK - Back up a RK05 device .RT-7 

Tektronix 4107 plotter routines. RT-13 

Tektronix 4662 plotter routines. RT-10 

Telephone Area Codes . RT-7 

Terminal emulator control package. RT-14 

THESIS . RT-12 

TIMING - system timing tests . RT-3, RT-8 

TSX+ System Services . RT-8 

TSX+ Utilities . RT-6, RT-8 

TSXLIB, Version 6.2. RT-8 


RT-17 


RT-18 











































































UCL+, Version 7.55 b . RT-9 

UP - IND Control File.RT-13 

VanSwaay, M. RT-14 

Visual 350 plotter routines. RT-13 

VT-200 Font Generator.RT-5 

Walker, W.RT-9 

Walraven, R. RT-4, RT-9 

WSHLST - Wish list survey. RT-4 




EXCHANGING INFORMATION WITH OTHER SYSTEMS 
VIA 

MAGNETIC TAPE UNDER RT-11 [1] AND TSX-PLUS [2] 


Introduction 


The need for the exchange of information between unlike computer 
systems is constantly growing. Many governmental and commercial 
organizations, such as the Federal IRS, various health related agencies, 
and some insurance carriers, are requiring smaller and smaller business 
firms to report data in machine readable form. The 1/2-inch 9-track 
magnetic tape is generally the preferred medium. 

Magnetic tape is the preferred medium because it provides a most 
convenient means for exchanging large amounts of information between 
unlike computer systems. Aside from selecting one of several bit 
densities, it is a true device independent medium. The only other 
viable alternative that comes to mind is the serial line. Even at 9600 
baud, the serial line transfers less than three and a half megabytes per 
hour. 


[1] RT-11 is a trademark of Digital Equipment Corporation. 

[2] TSX-Plus is a trademark of S & H Computer Systems, Inc. 


There are computers out there that speak in EBCDIC instead of in 
ASCII. Hence, if information is to be exchanged with one of those 
machines, the data must be converted. This is not a difficult task, but 
it is rather tedious. Conversions in both directions may conveniently be 
accomplished with a single table. 

Tape Formats 

Much of this form of interchange is done on simple non-ANSI 
magnetic tapes. These tapes contain some number of fixed length records 
and no labels. Some agencies, however, do require ANSI formats with 
volume label, file header label, and end-of-file label records, each of 
which is 80 bytes in length. On just about all tape formats, the 
logical end-of-tape (EOT) is indicated by two consecutive tape marks. 

The following information has been taken from the indicated 
paragraphs of ANSI X3.27-1978, “Magnetic Tape Labels and File Structure 
for Information Interchange", and annotated: 

1.2.2 The VOL1 label record may be 80 characters or more in length. 

(The RT-11 VOL1 label is 5 12 bytes in length.) 

5.2.3 A label record may be extended by padding. (RT-11 label records 
are padded out to 512 bytes.) 

6.1 Only ANSI X3.4-1977 characters (ASCII) may be used. (Tapes 
written in either EBCDIC or binary are are not ANSI!) 

6.3-3 Padding may be with any desired characters. (RT-11 pads label 
records with random characters and data records with nuls.) 

6.5 Data record length ranges are specified in the following ANSI 
standards and not in X3.27-1978. (Both RSTS [31 and VMS [3] 
documentation state otherwise, 18-2048.) 

X3-14-1973 (200 cpi, NRZI) 

X3-22-1983 (800 cpi, NRZI) 

X3-39-1973 (1600 cpi, PE) 

X3-54-1976 (6250 cpi, GCR) 

[31 RSTS and VMS are trademarks of Digital Equipment Corporation 
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ANSI X3.27-1978 specifies four levels of labeling and structure. 

RT-11 does not adhere to any one of these defined levels but uses a 
subset of the several levels combined. 

At times the information as written to a tape may contain more than 
one data record per tape record. This is known as record blocking. 
Where data records are relatively short, tape utilization is made more 
efficient by blocking a number of data records into one tape record. On 
occasion, the blocking factor is optional and may be used to circumvent 
some of the RT-11 imposed limitations to be discussed later. 

Some of the tape formats likely to be encountered are the RT-11 
"not quite ANSI" structure with its 512-byte label records, true ANSI 
structures with both single and multiple label records, the old DOS-11 
[4] and ROLLIN structures with their 14-byte label records, and simple 
unlabeled structures. The VMS COPY command produces a tape with 
multiple label records. The following attempts to diagram some of these 
structures for comparrison. 
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[4] DOS-11 is a trademark of Digital Equipmen Corporation. 
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All DEC [51 operating systems, except for RT-11, are capable of 
reading and writing magnetic tapes in DOS-11 format. Therefore, this 
format has become quite useful for exchanging information between DEC 
systems. 

RT-1 l's DIRECTORY command is capable of producing a directory of an 
ANSI magnetic tape. The /VOLUME option will not recognize the 80-byte 
volume label record. The tape may have either single or multiple label 
records. However, only the information in the first file header and the 
first end of file record for each file is used. The file size indicated 
is the number of data records rather than the number of 512-byte disk 
blocks. 


All RT-11 device handlers deal in byte pairs or words. Hence, data 
I/O buffers must start on even byte boundaries. To the MACRO-11 
programmer this means that ail read/write programmed requests deal in 
words. To the high level language programmer the same restriction 
applies to ail SYSLIB and MTLIB [6] read/write calls. 

The MTLIB sample application programs are written in FORTRAN using 
direct access files. This results in a further restriction for these 
utilities in that tape records must occur in four-byte chunks. However, 
the library routines contained in MTLIB are restricted to two-byte 
chunks. 


Programming Considerations 

The following program fragments compare some of the requirements 
for transferring data to or from a magnetic tape using MACRO-11, and 
FORTRAN with either SYSLIB or MTLIB calls. 

MACRO-11: 

.FETCH addr.dnam 

.QSET addr.qlen 

.LOOKUP area,chan,dblk,seqnum 


.SPFUN area,chan,func,buff,went 


RT-11 Restrictions 


.CLOSE chan 
.RELEAS dnam 


As mentioned earlier, RT-11 does impose its own set restrictions or 
limitations on the use of magnetic tape. All records on an RT-11 tape 
are 512 bytes or one disk block long. Only the first 80 bytes are 
meaningful in the volume label record, each file header label record, 
and each end-of-file label record. Actual data records frequently span 
a tape 512-byte tape record boundary. Record blocking is not a user 
controlled option. 


[51 DEC is a trademark of Digital Equipment Corporation. 


where: addr 

area 

buff 

chan 


is the address at which the handler is to be loaded or 
the new elements are to start. 

is the address of an EMT argument block. 

is the address of the I/O buffer. 

is a channel number. 


[6] MTLIB is a product of NAB Software Services, Inc. 
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dblk is a the address of a 4-word RAD50 descriptor block 

specifying the dev:filnam.ext to be operated on. 

dnam is the address of the RAD50 device name. 

func is a numerical code indicating the function to be 

performed. 

qlen is the number of new elements to be added. 

seqnum is the sequence or file number. 

went is the number of words or character pairs to be 
transferred. 

FORTRAN/SYSLIB: 

I = IFETCH (dnam) 

I = IQSET (qlen,area) 
chan = IGETC () 

I = LOOKUP (chan.dblk.O.seqnum) 


I = ISPFNx (func.chan.wcnt.buff) 


I = I CLOSE (chan) 
I = IFREEC (chan) 


where: area is the address at which the new elements are to start. 

buff is the name of the data buffer. 

chan is the integer number of the I/O channel. 

dblk is the name of the array containing the RAD50 

dev:fiinam.ext. 

dnam is the RAD50 device name. 

func is the integer number of the code for the function 

to be performed. 
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qlen is the integer number of new elements to be added. 

seqnum is the sequence or file number. 

went is the integer number of words or character pairs 

to be transferred. 

FORTRAN/MTLIB: 

I = IFETCH (dnam) 


CALL MTFOR (unit,func,bre,buff,iret) 


where: bre is the integer number of bytes or characters to 

transfer or records to skip. 

buff is the name of the data buffer. 

dnam is the RAD50 device name. 

func is the integer number of the code for the function 

to be performed. 

iret is the integer number of bytes or characters read 

or zero if a tape mark was encountered. 

unit is the ASCII name and number of the magnetic 

tape device. 

It should be noted that with both MACRO-11 and FORTRAN using SYSLIB 
calls, the programmer must be concerned about the availability of 
Q-elements and I/O channels. The approach offered by MTLIB is much 
simpler, requiring from two to five arguments, depending on the function 
being requested. In all programming situations the device handler may 
be LOADed with the monitor command rather than be FETCHed by the running 
program. 


N. A. Bourgeois, Jr. 

NAB Software Services, Inc. 

PO Box 20009 

Albuquerque, NM 87154-0009 
(505)298-2346 
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T&© FMtt Gum 

John M. Crowell 


Quick, Henry, the Flit! We've got BUGS! 

I hope that this is not too regular a feature of the Minitasker. Any RT-1 1 
bugs that come to my attention from month to month will be included here. 
They may be problems with RT-11 itself. Or they may be hardware 
problems that manifest themselves in unexpected ways in RT-11. Or they 
might be bugs found in DECUS Library programs or RT-11 SIG tape 
submissions. We have at one of each this month. 






A problem with the MS handler was reported by Terry Compton. This 
one seems to have been around at lease since V5.1, and it's still there in 
V5.4. Under certain conditions (I think that one of them is when the 
device goes off-line in the mmiddle of an operation.), a system crash 
results. The following exerpt of the handler code illustrates the problem. 

.NODULE TS,RELERSE=U05 i UERSI0H=02 / C0nnENT=<TSn Magtape Handler^ 


. 


COPVRIGHT (c) 1984 

BV 

. 


DIGITAL EQUIPMEHTCORPORRTION, 

MRVNRRD 

1 


RLL RIGHTS RESERVED. 


BNE 

TCL2ER 


10$: 

JMP 

MSDONE 


TCL1ER: 

BIT 

*FL$CIP,TB$FLG(R5) 



BNE 

5$ 



RTS 

PC 


4** 

in 

BIC 

*FL$CIP,TB$FLG(R5) 

< _ 


. IF DF 

MSJFSM 

1 



nou 

nSCQ,R3 1 



JMP 

$I1T 1 


. IFF 


1 



.FORK TSFBLK - 



JMP 

MS 



. ENDC 


Clearly, if you have file-structured magtape support, R3 is getting 
clobbered. Our best guess is that moving the .FORK as indicated will 
solve the problem, but so far nobody's tried it. If you're having the 
problem, try it, and do let us know. 


Dr. Bob Schor of the University of Pittsburgh reports that there's yet 
even another problem with the FPJ-11 floating-point accelerator chip 
for the 11/73 and 1 1/83. It seems that whenever the STCDF instruction 
causes the exponent to change, the sign bit is dropped. So if the double¬ 
precision number is negative and nearly equal to a power of 2, the sign 
will change, (e.g. -5 1 1.999999999 becomes +512.) So far, I haven't found 
that RT-11 FORTRAN-IV V2.8 doesn't exhibit, the problem (I don't know 
about V2.6.), but FORTRAN-77 does because it uses the STCDF comand in 
it's generated code. If you use the FPJ chip, try the following FORTRAN-77 
program. 

real*8 almost minus l^epsilon 

data epsiI on /1.d-8/ 

almost minus 1 = -( 1.dO - epsilon ) 

x = almost minus I 

if(x .It. 0.) then 

type *,'x has proper ualue: *,x 
e I se 

type * ; 'x has wrong sign: ',x 
end i f 
end 

As of the date of this submission, nobody at DEC has admitted that there 
is a problem, let alone announced an(other) ECO for the chip. As soon as 
I get word from DEC, it’ll appear in this column. 

******************************************************************************* 


On the Spring '86 SIG Tape there were some useful programs submitted by 
H. Reints of the Netherlands. There was, nowever, a time bomb. They 
don't work with Version 5.4 of RT-11. The programs DISK.SAV and 
RDIR.SAV both use a routine LOGDSK which attempts to read the LD 
translation tables. Unfortunately, the structure of the LD tables changed 
with V5.4 along with the way .SPFUN 372 works. DO NOT use the 
programs on the SIG Tape with V5.4 of RT-11. It will do unnatural things 
to your LD handler. Below is an updated version of the LOGDSK routine 
which returns the file name of a mounted LD device. This one works 
with V5.4, but no earlier versions. If you're using DISK, RDIR, or LOGDSK, 
rebuild them using this module before trying them on V5.4 of RT-11. 
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.TITLE LOGDSK 

.nCflLL .CSTflT,.DSTRT,.LOOKUP,.SPFUN, .PURGE,.SERR,.HERR 

; FUNCTION LOGDSK(UN IT,FILBLK,SIZE,URLOCK,RURIL) 

; INTEGER UN IT,FILBLK(4),SIZE,URLOCK,RURIL 

j This subroutine gets Information of a logical disk unit LDn: 
j Input arguments: 

; UNIT : contains the LD unit number of which info is wanted 

; Output arguments: 

; FILBLK : contains the physical deuice and file name in Radix50 

; or 4 zero words when the LD unit is not mounted 

; SIZE : contains the size of the file in blocks 

j URLOCK : 0 if write enabled, -1 if write locked 

; RURIL : 0 if file available, -1 if not, +1 if handler not loaded 

; Function value: 

; +1 : LD Table size mismatch: results meaningless, maybe fatal 

; 0 : normal return 

; -1 : error reading LD translation tables 

; -2 : no channel available 

.PSECT USERS I 


I dun it = 8. 
; LD.FLG bits 


j Number of entries in LD tables 
(This may change I ) 


Id.rdo = 40000 

Id.unt * 37400 

Iogdsk:: 

mov *-2,funval 
. serr 

movb *14.,r4 

1$: .cstat *area,r4,* IdtbI 

bcs 2$ 
decb r4 
bge 1 $ 

br 7$ ; Oops 


If set, LD unit is read-only 
Unit number of physical disk 
assigned to this logical disk 

Initialize function value 
Disable EHT error abort 
Find an available channel 


a I I channeIs in use 
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i nc 

funva 1 

OK, we got a channel 

. 1 ookup 

•area,r4,*db1k 

Open it to LD 

bcs 

3$ 


. spfun 

*area,r4,*372,* 1dtb1, 

*1 j Read LD tables 

bcs 

3$ 


c 1 r 

funva1 

Normal so far 

.purge 

r4 

Free the channel for later 

tst 

funva1 

1f error, bai1 out now 

bit 

7$ 


cmpb 

1d.num,* 1 dunit 

Do tables match? 

beq 

4$ 


i nc 

funva1 

No, set error, but data NRV be valid 

br 

7$ 


mov 

4(r5),r3 

Get address of F1LBLK argument 

c 1 r 

(r3) + 

Clear F1LBLK 

c 1 r 

(r3) + 


c 1 r 

(r3) + 


c 1 r 

(r3) + 


c 1 r 

@6(r5) 

Clear SIZE 

c 1 r 

@10(r5) 

Clear URLOCK 

c 1 r 

@12(r5) 

Clear RURIL 

mov 

®2(r5),r1 

Get unit number 

b i c 

*~c<1 dunit — 1>,r1 

Force it to be valid 

as 1 

r 1 

Unit*2 is offset in LD.FLG table 

mov 

r 1 , r2 


as 1 

r2 


as 1 

r2 

; Unit*8. is offset in LD.NRN table 

mov 

Id.fIg(r1),r0 


bp 1 

7$ 

; If bit-15 =0, LD unit not allocated 

b i t 

* 1d.rdo,rO 

; Is it read-only 

beq 

5$ 

dec 

@1 0(r5) 

; Yes, set URLOCK flag 

b i c 

*^c<1d.unt>,rO 

Isolate physical unit number 

swab 

rO 

and put it in low byte 

mov 

1 d.siz(r1),@6(r5) 

Copy size to SIZE 

mov 

4(r5),r3 

Point to F1LBLK 

add 

* 1d.nam,r2 

Point to name 

mov 

r2,r1 

Save it for .DSTfiT 
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** ** ** ** **** **** ***** 4c ** ***** ************* ***************** ***** ** ** * *** * 

This Code is subject to change if idunit is euer > 8. 


mou 

(r2)+,(r3) 

; Copy deuice name 

add 

*~R 0,rO 

; Hake unit RRD50 

add 

rO,(r3)+ 

; Add unit number to deuice name 


) “ 

mou 

(r2)+,(r3)+ 

; Copy file name 

mou 

(r2)+, (p3) + 

mou 

(p2)+,(p3)+ 


i nc 

e! 2(p5) 

j Set RURIL to +1 

. serr 


; Disable EfIT error abort 

.dstat 

•apea,pi 

; See if deuice exists 

bcs 

7$ 


tst 

area+4 

; Yes, is handler loaded? 

beq 

7$ 


c 1 r 

©12(r5) 

; Yes ; zero RURIL 

. 1 ookup 

# area ; r4,4(r5) 

; and 1ook for file 

bcc 

6$ 


dec 

©12(r5) 

; It's not there. RURIL = -1 

6$: .purge 

r4 

; Ue're done with the channel 

7$: .herr 


; Restore EtIT error abort 

mou 

(pc)+,rO 

; Return function ualue in RO 

funua1:.word 

return 

0 


area: . b 1 kui 

6 


dblk: .word 

"RLD ,0,0,0 


Idtbl: 

1d.id: . b 1 kw 

1 ; 

Fi 1 les with ^RLD 

id.num: . bI kb 

1 ; 

Number of LD units (8. in U5.4) 

. b 1 kb 

i ; 

(reserued) 

Id. fig: .blkw 

1 dunit 


Id.ofs: .blkw 

1 dunit 


Id.siz: . blkui 

1 dun i t 


Id.nam: .blkw 

4*1 dunit 



. end 
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To register for on-line submission to the Pageswapper dial: 

(617) 262-6830 

(in the United States) using a 1200 baud modem and log in with 
the username PAGESWAPPER. 

Articles for publication in the Pageswapper can be sent (US mail 
only — no "express" services please) to: 

Larry Kilgallen, PAGESWAPPER Editor 
Box 81, MIT Station 
Cambridge, MA 02139-0901 
USA 

Preference is given to material submitted as machine-readable 
text (best is Runoff source). Line length should not exceed 64 
characters and the number of text lines per page should not 
exceed 48 (these limits are particularly important for sample 
commands, etc. where simple text justification will not produce 
a meaningful result). 

Please do not submit program source, as that is better 
distributed on the VAX SIG tape. 

Please do not submit "slides" from DECUS Symposia presentations 
(or other meetings) as they are generally a very incomplete 
treatment for those readers of the Pageswapper who are not so 
fortunate as to be able to travel to Symposia. Please DO write 
articles based on such slides to get the content across to a 
wider audience than is able to attend. 

Change of address, reports of non-receipt, and other circulation 
correspondence should be sent to: 

DECUS U.S. Chapter 

Attention: Publications Department 

249 Northboro Road (BP02) 

Marlborough, MA 01752 
USA 

Only if discrepancies of the mailing system are reported can 
they be analyzed and corrected. 
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John D. Hoinville 
and 

Richard D. Piccard 

Educational Computing 
Kalamazoo College 
Kalamazoo, Michigan 

Abstract 

We present techniques through which all VMS user and system disk 
backups can be performed by operators whose only extra user 
authorization entries are for the "OPER" and "GRPNAM" privileges 
and an identifier such as "STUDENT__OPERATOR". We place Access 
Control Lists on the tape and removable-media disk drives that 
deny access to all users (including the operators) except those 
who have "BYPASS" privilege or a specific identifier. These 
methods have two primary advantages: all user disk backups are 
performed by command procedures, which reduces to minimal levels 
the chance of a catastrophic mistake, and the operators can 
legitimately be advertised to have no special access to the 
files they are backing up. 


I. Introduction 


It is difficult to resolve the conflicting goals of system 
security; file system invulnerability to hardware, software, or 
human failures; system availability to users (measured in both 
connect time and CPU cycles), especially during normal working 
hours; and the effective use of professional staff time. At 
Kalamazoo College we have developed a method of meeting the file 
backup goal that has minimal impact on our ability to meet the 
other goals. Although there are some refinements that require 
recent VMS updates, variations of these techniques should be 
usable on any VMS Version 4 system. The approach described here 
should be of particular interest for small educational 
installations, but many other sites cannot afford to use skilled 
programmers as operators either. 
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This paper is organized into four sections, as follows: II. Preparation 

I. Introduction 

II. Preparation A. Maintaining Operator Accounts 


A. Maintaining Operator Accounts 

B. Boot-time Measures 

C. File Access Control Lists 

III. Daily Operations 

A. Professional Staff 

B. Student Operators 

IV. Conclusion 

The heart of our approach is to perform all backups and system 
shutdowns from batch jobs that are submitted, /AFTER= a date in 
the far future, by user SYSTEM (or by someone else with "BYPASS" 
privilege) . The student operator is granted access to the batch 
jobs' log files by an ACL entry that is automatically propagated 
to succeeding versions. The student operator can manipulate the 
queue to release or suspend a job, having OPER privilege. 
However, the student operator cannot read other people's private 
files directly, having neither BYPASS nor READALL privileges, 
and also cannot read them indirectly from the removable media 
(disk or tape) backup copies, because of Access Control List 
entries on the drives. 

The hard parts are first, getting the identifiers, ACLs, and 
privileges done correctly (examples are included below) and 
second, creating a batch job to shut the system down, since the 
queue manager and all batch jobs vanish like the Cheshire Cat 
fairly early in the shutdown process! The solution to the 
second problem is to have the batch job (which is released by 
the student operator) include a RUN/DETACHED command to create a 
process that will shut the system down. This process is outside 
the purview of the job controller, hence survives the early 
shutdown of all queues. 


Our student operators use two accounts. The first is their 
personal student account, which has no special privileges or 
identifiers at all. The second is one of several long term 
accounts (usernames of the form OPERATORn, for n = 1, 2, ...) 
whose password is changed every academic term and whose OWNER 
field in SYSUAF.DAT is also changed to indicate the student 
presently authorized to use it. It is the OPERATORn accounts 
that have the STUDENT_OPERATOR identifier and the OPER and 
GRPNAM privileges. 

There are three steps involved in maintaining the student 
operator accounts: original creation, modification to operator 
functionality, and modification upon staff turnover. The 
original creation is by standard techniques, such as the 
ADDUSER.COM file presented in example 5-4 of the "Guide to 
VAX/VMS System Management and Daily Operations." Take pains to 
use a UIC code that gives all of the OPERATORn accounts the same 
group number, with no other users having that group number. The 
AUTHORIZE utility is used once interactively to create the 
STUDENT_OPERATOR identifier and later through a command 
procedure to grant it to the individual operator accounts. 

Using the OPERATORn accounts also helps for dealing with 
turnover in student workers. When a student leaves, only the 
OPERATORn account he or she used need be modified. This keeps 
management of the OPERATORn accounts (and hence, who has access 
to the OPER and GRPNAM privileges) to a minimal level. 

B. Boot-time Measures 

ACLs for Devices 

Since the tape and removable media disk drives are being used by 
the operator, the protection of those devices is especially 
important. There are often extended periods of time when 
previously used tapes or disk packs are physically mounted. 
This could constitute a terrible security hole, since the 
operators or other users might allocate the drive, mount the 
volume, and read the contents. The backup command procedure 
does indeed allocate the device, so that no interference will 
occur while it is in use, but that happens only when it is 
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actually time to write the new backup copies of the files. We 
escape from this nightmare, as shown in Fig. 1, by the simple 
expedient of placing Access Control Lists (ACLs) on the drives. 


| Figure 1 | 


$! 

$! Set protection so that users with the identifier 

$! EDCOMPSTAFF can access tape and disk drives. 

$ 1 

$ EDCOMP :== SET DEVICE/ACL=(- 

(IDENTIFIER=EDCOMPSTAFF,- 

ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL) , - 
(IDENTIFIER^*, *] , ACCESS=NONE) ) 

$ ! 

$ EDCOMP MSAO: 

$ IF ("" f$trnlnm( ,, sys$sysdevice M ) ' ” .NES. M DJA0: M ) 

THEN EDCOMP DJAO: 

$ ! 


Figure 1: Creating Device ACL's in SYSTARTUP.COM. 

The ACLs achieve several useful functions: the professional 
staff (who have need, or who know the SYSTEM passwords, and 
hence could get to it anyway) are granted full access to the 
drives; any job, typically with [SYSTEM] UIC, that has BYPASS 
privilege (such as the BACKUP jobs) gets access anyway; all 
other processes are denied access, including ordinary users and 
the student operators. The ACL is applied to the RA-60 only if 
it is not the system disk, since users MUST have access to many 
files on the system disk! 

Group Logical Names 

The student operators use their group logical name table to 
communicate to the backup batch job in the event that a fatal 
error or other catastrophe requires that the BACKUP command 
itself be re-issued. As discussed in part III, our backup 
command procedure includes code that must be executed only once, 
so that re-trying the BACKUP command must be possible. Besides, 
what system manager likes to be awakened by a phone call at at 
6:20 AM from the student operator asking to have the backup job 
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re-submitted! In order for the group logical name table to 
exist, at least one name must continue to be defined in it. 
Figures 2 and 3 show how this is done; the input command 
procedure specified in Fig. 2 is presented in Fig. 3. The 
technique of running LOGINOUT to process a DCL input file was 
documented in the Release Notes for VMS V4.1, page 4-2 (thanks 
go to the Colorado Customer Support Center staff for digging up 
this reference). 


| Figure 2 


$ ! 

$! Run the job that creates the operator group [50,*] 

$! logical name table, for use by BATCH_SUBSETBACK. 

$ ! 

$ RUN/DETACH/UIC=[OPERATOR1]- 

/INPUT=SYS$MANAGER:OPERATOR_LNMTBL.COM- 
/OUTPUT=SYS$MANAGER:OPERATOR_LNMTBL.LOG- 
/PROCESS_NAME=OPERATOR_LNMTBL- 
SYS$SYSTEM:LOGINOUT 

$ ! 


Figure 2: Creating Group Logical Names in SYSTARTUP.COM. 
(Input file is presented in Fig. 3.) 
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| Figure 3 I 


$ 

$ ! 
$ 

$! 
$ ! 
$! 
$ ! 
$ ! 
$ ! 
$ ! 
$ ! 
$ ! 
$ ! 


DEFINE/GROUP STUDENT_OPERATOR_GROUP - 

" D 0_N 0 T_DE LE TE__T HI S_LOG IC AL_NAME ” 

EXIT 


SYS$MANAGER: OPERATOR_LNMTBL . COM 

Executed by a RUN/DETACH/UIC=[OPERATOR] command in 
SYSTARTUP so that the [50,*] group logical name table 
will exist for reference by BATCH_SUBSETBACK.COM. 


Figure 3: Input file for creating the OPERATORn 
group logical name table (see Fig. 2). 

PRIVBATCH 

The backup and system shutdown batch jobs are submitted to a 
privileged (or private) batch queue, PRIVBATCH, so that they 
cannot be shut out by user jobs. That queue is created as shown 
in Fig. 4. The memory management values proved essential for 
efficient analysis of accounting data, they are extravagant for 
backups. (Before we learned how large to set WSEXTENT, one 
quarterly accounting summary provoked 6 million page faults!) 
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| Figure 4 | 


$ ! 

$ INITIALIZE/QUEUE/BATCH/START/J0B_LIMIT=5- 

/WSDEFAULT=102 4/WSQUOTA=35 00/WSEXTENT=35 0 0- 
/BASE_PRIORITY=4/PROTECTION=(S:RWED,0,G,W) - 
PRIVBATCH 

$ ! 


Figure 4: Creating PRIVBATCH in SYSTARTUP.COM. 

C. File Access Control Lists 

In order to allow a student operator to monitor the command 
procedures for errors, including BACKUP'S soft tape write errors 
(which we track as an indicator of wear on re-cycled tapes), the 
student is granted the STUDENT_OPERATOR identifier. By giving 
the log files the correct ACLs, the student operators can access 
these files while leaving the rest of SYSTEM'S log files secure 
from browsing. This reduces temptation the student operators 
might experience when it comes to looking into areas where they 
should not be allowed. 

Figure 5 shows the protection of a typical backup log file. Two 
methods can be used to create ACLs for the log files. One 
method is to set the ACL for the file with the VMS "SET ACL” 
command, the other method is to EDIT/ACL the file. An example 
of the former method is as follows: 

$ SET ACL/ACL=(IDENTIFIER=STUDENT_OPERATOR, 

ACCE S S=READ) EX.LOG 

Note that if this file had an existing ACL associated with it, 
this new ACL entry would be put at the top of the ACL list. The 
new entry could instead be added to the end of the ACL list with 
the "/AFTER" option. 
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I Figure 5 | 


$ DIRECTORY/SECURITY SYS$MANAGER:BATCHBACK.LOG 

Directory SYS$SYSROOT:[SYSMGR] 

BATCHBACK.LOG;24 [SYSTEM] (RWED,RWED,RE,) 

(IDENTIFIER=STUDENT_OPERATOR, ACCESS=READ) 


Figure 5: Log file ACL. 

Another way to create or modify an ACL is to invoke the ACL 
editor. By using the ACL editor, a file with the correct ACL 
can be created and then other files can be given the same ACL 
using the command 

$ SET ACL/LIKE=OBJECT_NAME=filename_with_ACL - 
filename_needing_ACL 

This command was not correctly described in early VMS Version 4 
documentation. 


Ill. Daily Operations 


A. Professional Staff 

BACKUP Jobs 

The student operators can control the start of the backup 
because the submission command specifies execution at a later 
date that is hundreds of years in the future, so that the job 
will not run until an operator intervenes. Because of the 
complexity of the submission command, the system manager uses an 
interactive command procedure to perform the submission. We 
have such procedures for submitting the jobs that will perform 
overnight backups of new files, that will shut the system down 
for stand-alone backup of the system disk, that will perform 


full backups of specific user file directory trees, etc.. 

Figure 6 shows the critical portion of the command procedure 
that submits the procedure BATCH_RA60BACKUP.COM, which we use to 
write tape copies of RA-60 packs, typically the oldest existing 
disk pack copy of the system disk. The procedure prompts for 
the saveset name if the name was not supplied. Once a saveset 
name is supplied, the backup procedure is submitted to the batch 
queue named PRIVBATCH, for execution after the 18th of September 
in the year 3500. Of course that wait will never be fulfilled; 
the job is held until an operator intervenes, as discussed in 
part B of this section. 

By having the queue manager hold the job, there is virtually no 
CPU or memory used until it is actually time to execute the 
backup. In these respects it is superior to our original 
inspiration. That involved submission, by the backup or 
shutdown job, of another job that consisted of an infinite loop 
of 23 hour WAIT commands. Then, in the backup or shutdown job, 
that submission was followed by a SYNCHRONIZE command. When the 
time came to proceed, the student operator would delete the 


| Figure 6 | 


$ BEGIN: 

$ ! 

$ IF PI .NES. "" THEN GOTO START 
$ INQUIRE/NOPUNCTUATION PI - 

"SUPPLY SAVE SET NAME (e.g., SYSTEMC.BCK): " 

$ GOTO BEGIN 
$ ! 

$ START: 

$ ! 

$ SUBMIT/QUEUE=PRIVBATCH/NOTIFY/PARAMETERS=("''PI'") - 
/NOPRINTER SYS$MANAGER:RA60BACKUP.COM - 
/NAME=BATCH_RA60BACKUP/AFTER=18-SEP-3500 

$ ! 

$ EXIT 


Figure 6: A Simplified Submission Procedure. 
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WAITing job, which would satisfy the SYNCHRONIZE and release the 
backup or shutdown job. This was clumsy, but it did work. It 
required a separate queue ("SYNCQUEUE"), consumed memory for 
both jobs, as well as a little CPU for the WAIT loop, and 
consumed active job slots in the PRIVBATCH queue. 

On our system we have located all user files in a directory tree 
whose root is DUA1: [USERFILES] . The files are split into three 
groups, in subdirectories MONDAY, WEDNESDAY, and FRIDAY, and the 
pseudodevices MON:, WED:, FRI:, and USER: are defined at boot 
time by the logical name assignments in Fig. 7. (USER: is a 
search list for the other three, for use when you don't know 
which group a given user's files are in.) We backup all files in 
each subtree once a week, on the obvious day. 


| Figure 7 | 


$ ASSIGN/EXEC/SYSTEM/TRANSLATION= (CONCEALED, TERMINAL) - 

DUA1:[USERFILES.FRIDAY.] FRI: 

$ ASSIGN/EXEC/SYSTEM/TRANSLATION= (CONCEALED, TERMINAL) - 

DUA1:[USERFILES.WEDNESDAY.] WED: 

$ ASSIGN/EXEC/SYSTEM/TRANSLATION= (CONCEALED, TERMINAL) - 

DUA1: [USERFILES.MONDAY. ] MON: 

$ ! 

$ ASSIGN/EXEC/SYSTEM FRI:,WED:,MON: USER: 

$! 


text can be passed on to DCL through the LIB$SET_SYMBOL routine. 

We chose to implement the group logical name approach, rather 
than the SNDOPR approach, because the code is simpler and we 
could implement it with confidence more rapidly. Even if 
information more complex than a YES or NO type choice must be 
communicated, the group logical name approach should be 
considered. It will not work, of course, unless the batch 
process and the operator have either the same UIC group number, 
an identifier that matches an ACL on the group logical name 
table, or BYPASS privilege. (See the PAGESWAPPER for April, 
1986, pages VAX-2 and VAX-3 for techniques of placing ACL's on 
logical name tables.) 

SHUTDOWN for S/A BACKUP 

Figures 8 and 9 provide the means for the student operator to 
shut the system down. Figure 8 is the batch job, submitted 
/AFTER=18-SEP-3500 by SYSTEM, and Fig. 9 is the input command 
file for the process that it creates after the operator releases 
it. There is no EXIT at the end of Fig. 9, because by then the 
system is shut down! This is essentially a variation on the 
technique used to create the group logical name table: run 
LOGINOUT so that DCL is available, and specify a command 
procedure as the input. Here, the input command procedure 
invokes SYS$SYSTEM:SHUTDOWN, with parameters specified so that 
no interactive session takes place. Presumably we are 
vulnerable here to changes in the parameter definitions of 
SHUTDOWN that DIGITAL might choose to make in future versions of 
VMS (are you listening, developers?). 


Figure 7: Creating pseudodevices in SYSTARTUP.COM. 

The procedure we actually use also performs several tasks at the 
beginning and end on specific days. Some of these we do not 
want repeated, so provision must be made to loop back over the 
BACKUP command itself in case something should be wrong (fatal 
tape drive error, etc.). That is done through a group logical 
name for the student operators' UIC group (50 in our case) . 

An alternative method to achieve the batch mode equivalent of 
the interactive INQUIRE command would be to write a program (in 
MACRO, FORTRAN, or PASCAL) that uses the SNDOPR (or SYS$SNDOPR) 
system service, which is documented on pages SYS-429 through 
SYS-442 of the VAX/VMS System Services Reference Manual. Once 
the program has captured the text of the operator's reply, that 
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| Figure 8 | 


| Figure 9 I 


$ 

$ 

$ 

$ 

$ 

$ ! 
$! 
$! 
$ 


$ ! 
$ 

$ ! 
$ ! 
$ ! 
$ ! 
$ ! 
$ ! 
$ ! 
$! 
$! 
$! 


SET NOON 

ON ERROR THEN EXIT 
SET LOGINS/INTERACTIVE=0 
REPLY/USER/BELL/BELL - 

"THE SYSTEM IS SHUTTING DOWN FOR BACKUPS. PLEASE LOGOUT!" 
WAIT 0:2:0 

Start detached process to shutdown the system 

RUN/DETACH/UIC=[SYSTEM]- 

/INPUT=SYS$MANAGER: CALL_SHUTDOWN. COM- 
/OUTPUT=SYS$MANAGER:SHUTDOWN.LOG- 
/PROCESS_NAME=CALL_SHUTDOWN - 
SYS$SYSTEM:LOGINOUT 

EXIT 


SYS$MANAGER: BATCH_SHUTDOWN. COM 
Allows an operator to bring the system down. 


$ 

$ 

$ 

$ 

$ ! 
$ ! 
$ ! 
$ ! 
$ ! 
$ ! 
$ ! 
$ ! 
$ ! 
$ ! 
$ ! 
$ ! 
$ ! 
$ ! 
$ ! 
$ ! 


ASSIGN OPAO: SYS$OUTPUT 
DEL*ETE :== DELETE/NOCONFIRM 
SET NOVERIFY 

0SYS$SYSTEM:SHUTDOWN 0 "Stand-alone backup" "N" "Y" - 

"BY 8 AM" "N" "REBOOT CHECK" 


SYS $MANAGER:CALL_SHUTDOWN.COM 

SHUTDOWN.COM parameters have the following meanings: 

PI = Minutes until shutdown 
P2 = Reason for shutdown 
P3 = Spin down disk volumes 

P4 = Invoke site-specific shutdown procedure 
P5 = When will the system be rebooted? 

P6 = Perform automatic reboot? 

P7 = Shutdown option 


Figure 9: SHUTDOWN Procedure Detached job input. 
B. Student Operators 


BACKUP Jobs 

Figure 8: SHUTDOWN Procedure Batch job. 

The OPERATORn accounts have a LOGIN.COM that includes 
REPLY/ENABLE and then REPLY/STATUS to find out whether any 
outstanding requests need to be satisfied (such as mounting a 
second tape volume for the overnight backup). If such is the 
case, then the operator mounts the next tape and issues a 
command of the form 
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$ REPLY/TO=request-number 

using the request number indicated by the REPLY/STATUS output. 
The operator checks the overnight incremental backup log file 
(with an ED IT / TPU / READ_ONL Y command) to verify that all went 
well. 

Once the incremental backup is completed, the operator finds and 
mounts the first tape for that day's backup. Then the backup 
job needs to be released. There are two steps: first, find the 
entry number; second, SET that entry of the QUEUE to /NOAFTER as 
follows: 

$ SHOW QUEUE/BATCH/ALL PRIVBATCH 


$ SET QUEUE/ENTRY=entry-number/NOAFTER PRIVBATCH 

After the above command is entered, the command procedure is 
immediately queued up for execution. The operator replies to 
mount requests and problems that may arise during the backup. 
The first request is usually that the operator mount a tape. 
The syntax of the reply is as discussed above. When each reel 
is finished, the operator receives another request to mount the 
next volume, loads the next tape, and replies to the request. 

If the procedure makes a request to "REPLY TO CONTINUE, USE 
DELETE/ENTRY= etc. TO ABORT JOB", then the procedure has 
encountered an error. Before responding , the operator logs in 
on a screen terminal and edits the log file with the command: 

$ EDIT/TPU/READ SYS$MANAGER: BATCH_SUBSETBACK . LOG 

If the only errors are "file access" errors that occurred while 
backing-up the files or "file not found" errors that occurred 
during the verify or the recording pass, or verification errors 
for blocks in MAIL or directory files, then all is normal for 
backups performed on an active system and the operator continues 
the procedure by replying to the request. If there is a FATAL 
type error message during the backup, we want to have it re-do 
just the tape writing part of the procedure. That will happen 
if, before replying, the following line is executed by 
OPERATORn: 


$ ASSIGN/GROUP "SHUCKS" BACKUP_ABORTED 

Then the operator replies to the request so that the procedure 
continues. Immediately following the BACKUP (but not executed 
until after the REPLY, if BACKUP exits with warning or worse 

status) is a check of the logical name BACKUP_ABORTED in the 

group table for the [OPERATORn] UIC. 

If such a catastrophe has happened, and the above recovery 
started, then the request "Reply when FIRST tape is ready 
again." will appear. The operator waits for the tape on the 
drive to rewind and then mounts the first volume of the tape 

set, again, and replies to the request. As soon as the backup 

is underway successfully, the following command must be issued 
by the operator, before the backup completes: 

$ DEASSIGN/GROUP BACKUP_ABORTED 

In summary, the logic in BATCH_SUBSETBACK.COM is to test, 
immediately following completion of the tape-writing, whether 
the logical name BACKUP_ABORTED has any translation; if it does, 
then the procedure loops back to the BACKUP command itself. 

If one reel has a problem, the operator may get a message like 
"Request 8, Continue, Retry, or Abort". In that case the usual 
correct response is 

$ REPLY/T0=8 "RETRY” 

When the subset backup has completed, the operator types the log 
file on the operator's console, with the command: 

$ TYPE SYS$MANAGER:BATCH_SUBSETBACK.LOG.0 

This maintains a hardcopy record of these operations. 

SHUTDOWN and S/A BACKUP 

We instruct our student operators to use the REPLY/USER command 
to inform current users that a shutdown is impending. If time 
is not too pressing, the operator waits until all users have 
logged off before releasing the batch job to shut the system 
down (see Fig. 8). That job itself sets interactive logins to 
zero, announces the impending shutdown, and waits another two 
minutes. This extra time is invested as a matter of policy, to 
be sure that even if the student operator neglects to announce 
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the shutdown, our users will have had fair warning. 

Stand-alone BACKUP of the system disk is perhaps the most 
delicate of the procedures that we entrust to student operators. 
If they type the BACKUP command with the device names in the 
reversed order, then the system disk will be wiped out! We do 
reduce our vulnerability by not pre-initializing the disk pack 
that they are supposed to be writing onto (but in this disaster 
scenario would copy from) . Thus an older copy of the system 
disk would be "restored" and only software updates, batch jobs 
pending, and user authorization file changes, made during the 
intervening period (three weeks as we do these things), would be 
lost. All but the last week's worth would be recoverable from 
other packs. After the system has rebooted, the operator logs 
in and uses REPLY/ALL to notify waiting users that the system is 
up for the day. 


IV. Conclusion 


Performing backups from batch jobs liberates the operator, 
whether professional or student, from having to loiter in the 
machine room. Instead, we can perform useful work while the 
backups are in progress, knowing that OPCOM will alert us to the 
need to change volumes. In addition, the techniques described 
here permit less-skilled operators to relieve the more skilled 
staff both of the need to arrive in the wee hours to initiate 
backup jobs, and also of the time consuming tasks of supervising 
command procedures and changing tape volumes. 

We would like to thank several people who have contributed to 
the development of the techniques reported here. Amy Courter 
and Mary Haug developed the command procedures used for daily 
operation of our system. Forrest Piehl created the initial 
versions of the techniques reported here (using the SYNCHRONIZE 
command, as discussed above in section III, part A), including 
the code shown in Figs. 8 and 9 that permits student operators 
to shut the system down for stand-alone backup of the system 
disk. Finally, we thank the student operators who had to learn 
and deal with the various modifications and changes as we 
debugged each new inspiration: Kelly Baldrica, Daryl Dickhudt, 
Kenneth Dietz, In Bum Eom, Ernest Johnson, and Greg Lewis. 


VMS User’s Network Working Group 


Jamie Hanrahan 
Working Group Chair 


This is a summary of the results of the meetings of the "Usenet 
for VMS Working Group" at the Spring '87 DECUS Symposium. 


Background 


(Those already familiar with the working group and its goals may 
skip this section.) 

Unix(TM) sites have for many years enjoyed the benefits of 
"Usenet",* a worldwide network of (mostly) Unix systems 
connected (mostly) via 1200 bps autodialed phone lines. The 
services provided by this network are electronic mail and 
"Netnews", an elaborate on-line conferencing system. 

The Usenet has been of incalculable value to the Unix community. 
The network encompasses over 10,000 systems, crossing both 
corporate and geopolitical boundaries; the body of knowledge 
that is available from the participants is not inconsiderable. 
Questions posted to Netnews on almost any topic are generally 
answered within a few days. Bug reports and fixes, patches to 
Unix system code, and public-domain software are all distributed 
through Usenet; many sites justify the telephone expenses 
(which, for sites with many connections, are not small) on this 
basis alone. Further, Usenet is effectively part of the 
Internet, which includes Arpanet, CSNET, and BITNET...#not to 
mention Easynet, DEC'S internal DECnet network. 


* I am aware that, according to some authorities, the term 
"Usenet" only applies to Netnews, and the mail service should be 
referred to as "uucp mail" (a reference to the principal 
transport mechanism). But it is awkward to keep saying "Netnews 
and uucp mail". You know what I mean. 
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VMS users who are aware of Usenet have for many years wished for 
a way to connect to it — not only so we could talk to all those 
other folks, but also (or especially) so we could talk to each 
other. There has never been anything technically impossible 
about this, but the necessary software and information has not 
been cheaply available in the correct combinations. A few years 
ago some of us got together at a DECUS Symposium, started 
calling ourselves a Working Group of the VAX SIG', and set out to 
do something about the problem. 

To talk to the existing Unix systems in the network requires, 
first of all, a transport mechanism. The systems on Usenet 
mostly use uucp (Unix-to-Unix Copy), a facility that has been 
part of Unix since the early days. We considered writing uucp 
for VMS and rejected the notion, partly because AT&T regards the 
algorithms expressed in the Unix sources as trade secrets, 
partly because uucp isn't particularly efficient, and partly 
because we thought we hoped to find something else off the 
(low-cost) shelf. 

Our next candidate for the transport mechanism was Kermit. 
Kermit, like uucp, is a file transfer protocol, not a general 
protocol for task-to-task communications; but that is fine for 
our purposes, since all news and mail traffic on Usenet is 
shipped from one system to another as files. Good 
implementations of Kermit already exist for both VMS and Unix. 
The Unix version is written in C and can autodial, negotiate 
login sequences, and generally do everything that uucp can do. 
There is a VMS version of C-Kermit which needs a little bit of 
polishing but can also perform all of the required functions. 
(The standard VMS Kermit — the one written in Bliss — cannot. 
Polishing C-Kermit/VMS will be a far easier job than adding the 
autodialing, login script, etc., features to Bliss Kermit.) As 
for efficiency, standard Kermit does not do very well, but if 
"sliding window" support is added* it can approach 90% line 
utilization. 

Accordingly, I contacted Frank da Cruz about the possibility of 
my working on C-Kermit/VMS, and acquired the job. I got as far 
as getting automated, batch-mode file transfers to work between 
VMS systems, and my Unix-speaking acquaintances assured me that 
the scheme I was working on could be easily supported from the 
Unix side. This is where things stood before the Spring '87 


*See Kermit — a File Transfer Protocol by Frank da Cruz 
(Digital Press, 1987). 


Symposium in Nashville. 


Recent Developments 


Todd Aven appeared at the working group meeting and said 
(approximately), "Why don't you use PMDF?" Further discussion 
during the meeting, after the meeting, and at another meeting 
held later in the week established that: 

o PMDF (Pascal Memo Distribution Facility) is available 
at low cost. (Details are in a later section.) 

o PMDF can do everything we need in the way of a 
transport mechanism between VMS systems. 

o PMDF can speak to MMDF (Multi-channel Memo Distribution 
Facility), which is distributed with Berkeley 4.3 Unix 
systems, thus allowing connections with the Unix world 
(and thence with Internet). 

o PMDF includes an interface to VMS Mail, thus, part of 
the application layer is done. (The other part is a 
news system, about which more later.) 

o In addition to autodialed phone links, PMDF can use 
other channels, including DECnet, JNET*, and TCP/IP 
(Wollongong or Tektronix implementations). There are 
provisions for user-written support of additional 
channels. 

(A few people at the meeting expressed some dismay at the 
thought of throwing away what's been done so far on 
C-Kermit/VMS, but I didn't; very little of what I've done is 
specific to the use of Kermit as a network transport mechanism. 
I'm still working on the C-Kermit/VMS code and expect to ship 
some files to Columbia University within a few weeks [famous 
last words].) 

There are other nice things about PMDF. Since it can 


* JNET is a VMS-to-IBM_RSCS product, and is a product of Joiner 
Associates, Inc. 
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conveniently use DECnet channels, and can delay use of such 
channels until a prescribed time of day or night, we may well be 
able to build a high-speed "backbone" for our network by using 
long-distance DECnet leased lines during off hours. (Many 
companies have such lines between facilities in widely-scattered 
locations, and nearly all such lines are idle at least twelve 
hours per day.) 


What's Being Done Now 


So, now that the software is available, we can start making 
connections, right? Well, almost. 


PMDF or UUCP? 


A public-domain uucp, "uuslave", is being developed. It does 
not at present do everything required (no autodial, no login 
script negotiation, etc.), but it does speak the uucp protocol 
and it has been certified by AT&T as not having been derived 
from Unix sources. If this can be turned into a relatively 
complete uucp emulator for VMS, it would be preferable to PMDF. 
Not all Unix systems can talk to PMDF; if we could use uucp we'd 
have a vastly larger number of potential gateways to the 
existing Unix network. It would also simplify the node 
addressing issues (see the next few sections). 


Ad-Hoc Networks in the Internet Age 


If we let our network "just grow", we will fall prey to many of 
the problems currently faced by Usenet sites. We could just 
start making connections, but the network will be far more 
beneficial to all of us if we do a bit of homework first. To 
make it as easy as possible to talk among ourselves and to the 
rest of the world, we should go to the trouble of becoming an 
officially recognized part of the Internet.* 


I am currently making inquiries as to how we might best connect 
with the existing Internet; until we have at least some 
information here, it would be wise not to proceed hastily. (But 
see "What You Should Do Now", below.) For some sites this will 
not be a problem: They will simply connect to a system that's 
already on the Internet and which is willing to perform domain 
server functions for them, and that will be that. But the rest 
of us will need, collectively, to become a zone, a domain, or a 
subdomain of our own, or else find a way to join an existing 
one. (Which is most suitable depends on what sort of resources 
we can scrounge up. It is not unreasonable to suppose that 
DECUS, or some part of DECUS, might provide the "responsible 
organization" to act as the administering authority of a new 
Internet domain [perhaps decus.org], but this remains to be 
seen.) 


Joining the UUCP Zone 


One option is to register new domains through Stargate 
Technologies, a not-for-profit, volunteer organization that is 
providing name registration services for the .uucp zone of 
Internet. To do this you need to find a nearby Unix system 
which has the MMDF software and whose administrators are willing 
to give you a connection. As long as your site is reachable by 
what appears to be uucp (i.e. via "bang style" addressing), it 
doesn't matter that the actual transport mechanism is something 
other than uucp. 

Registration for your organization through Stargate costs $150 
per year; sign up and the rest of the Internet will recognize 
your organization as a domain and will properly handle mail to 
and from you. If you are the ABC company, your domain might be 
called abc.com . You can then add other systems to the routing 
tables on your "gateway" machine; the rest of the net doesn't 
need to know about those (since all traffic to and from the rest 
of the net will funnel through the gateway). Thus you can have 


* Please do not call or write to tell me that "only DoD-approved 
sites can connect to Internet". This was true when Arpanet and 
Internet were synonymous. Today, Arpanet is the ".arpa" zone of 
the larger Internet. Other zones include .bitnet, .csnet, and 
.uucp . 
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eng.abc.com, sales.abc.com, etc., each subdomain representing a 
department. Stick a user name and an n @" on the beginning (i.e. 
yourname@eng.abc.com) and you have a complete Internet address 
for yourself, such as smith@eng.abc.com . 


News System Issues 


PMDF provides the transport mechanism and the mail application. 
Everyone involved in this project agrees that Netnews, or 
something like it, is also essential to the growth and health of 
this sort of network. A news system provides an effective 
replacement for network-wide "mailing lists", which can be 
expensive and difficult to maintain. Besides, with mail you can 
only exchange messages with already-known people; news lets you 
find people you might like to send mail to. 

The existing netnews software cannot, as far as I can determine, 
be compiled under the VAX-11 C compiler. (I've tried; if 
someone else has had better luck, please let me know.) It can be 
compiled and run under Eunice (Wollongong's Unix-on-top-of-VMS 
product) , but it is not reasonable for us to require sites to 
buy Eunice just to participate in the network. 

Therefore, I am working on a VMS-specific news implementation. 
It is composed of four major components: Database server, 
import and export programs, and user interface. The components 
communicate with each other using a slightly modified version of 
Brian Kantor and Phil Lapsley's Network News Transfer Protocol 
(NNTP) ; the biggest change (and it's a minor one) is that the 
communication paths are VMS mailboxes or DECnet logical links, 
rather than character-oriented channels like TCP/IP (which is 
what NNTP expects). 

This design will permit users on different VAXes on a LAN to 
access a common news database on a single machine; it will not 
be necessary to maintain the news on every machine where it 
might be read. It will also be easy to build alternate user 
interfaces without having to deal with the complexities of the 
news database. The database itself stores the articles in 
individual text files, with RMS indexed files acting as indices 
to the articles. 


More information on the news software will appear in the next 
Working Group report, which I hope will be ready for next 
month's PAGESWAPPER. The job still looks relatively simple at 
this stage; I think I can comfortably promise that I'll have the 
news software ready before we get the addressing/domain 
questions resolved. 


Too Much of Anything, Even News, is Not Necessarily a Good 

Thing 


In the meantime, you might consider the following issue: Usenet 
is currently laboring under a proliferation of news text. With 
10,000 sites and untold legions of users producing ten megabytes 
or so of news a week, the network backbone links are saturated 
or nearly so, and nobody has time to read it all. 

Fortunately you don't have to read it all; it's easy to ignore 
the topics ("newsgroups") you're not interested in, just as you 
avoid subscribing to every magazine that's available. But the 
backbone sites must still ship all of it everywhere. (Perhaps 
nobody at your site reads the newsgroup on Celtic cooking, but 
someone at one of the sites you feed might do so.) As a result 
of the proliferation of newsgroups and contributions thereto, 
both the phone line time and the disk space are becoming 
prohibitively expensive for many Usenet participants. Many 
sites (other than those that make up the backbone) have ceased 
forwarding what they consider to be "nonessential" newsgroups. 

We will face this issue sooner or later. Should we decide at 
the outset that only technically-oriented newsgroups will be 
established? Or that there will be "mandatory" and "optional" 
newsgroups, and sites on our network will only be required to 
store and forward the "mandatory" ones? (Through the primary 
links, anyway. Sites would of course be free to establish 
additional links, over which they might receive and send news 
that they wouldn't get from the backbone. I believe that some 
of this is already happening on Usenet.) 

With any sort of restrictive policy, we face the questions of 
"who will make the decisions” and "how will they arrive at their 
decisions", and whatever policies are adopted, it seems certain 
that some people will be # unhappy. (Should this working group, 
or some other agency of DECUS, set the policies? If so, will we 
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be unable to use the network to exchange information (like 
product pricing) that conflicts with DECUS's canons of conduct?) 
But the Usenet experience indicates that without such a policy, 
the network will soon become untenable; presumably, this will 
make nearly everybody unhappy. 


Minor Issues: The Name Game 


Those of you who have been following this effort for some time 
will have noticed that the title of the article says "VMS User's 
Network Working Group" instead of "Usenet for VMS Working 
Group" — the latter being our original name. This name change 
was made at Larry Kilgallen's suggestion that the idea of a "VMS 
User's Network" would have a broader appeal than the idea of 
"Usenet Access for VMS" — since, after all, most VMS users 
would like a convenient way to talk to each other, while only a 
small fraction of the VMS community may be aware of Usenet and 
the desirability of connecting to it. 

I'm not entirely happy with the name "VMS User's Network" (which 
will probably be shortened to VUnet, which sounds too catchy not 
to have been used before, or even [God help us] Vusenet) , but it 
seems to describe what we're trying to do. If you have a better 
idea for a name, I'd be happy to hear it. On the other hand, 
I'm not inclined to spend much energy worrying about this. 


What You Should Do Now 


Acquire and Install PMDF 


At this writing it is likely that PMDF will play an important 
role in the network, so if you want to join quickly, you would 
be wise to acquire it. PMDF is available for the cost of 
distribution. 


Ned Freed 
The PMDF Project 
Computing Services 
Harvey Mudd College 
Claremont, CA 91711 
(714) 621-8006 

It will come on nine-track tape (VMS BACKUP format) with about a 
hundred pages of documentation. (If your organization makes it 
difficult to buy software without prior approval, tell them that 
it's a book that happens to come with a tape instead of the 
other way around. Or just tell them it's a book.) Read the 
documentation, install PMDF on your system(s), and become as 
familiar with it as you can. 

(Even if you don't care about joining our network, you can use 

PMDF if you're using VMS Mail over DECnet. Have you ever been 

frustrated when trying to send mail to someone who lives on a 
node that's temporarily unreachable? PMDF will automatically 
spool the mail for transmission when the link is up. You'll 
have to give a "To:" address that specifies routing through 

PMDF, but that can be handled via logical names.) 


Learn About Internet 


Find someone in your organization, DECUS LUG, or other nearby 
tribe who knows something about Internet. This should not be 
difficult; most large universities and many small and large 
corporations are on the Internet, and there should be someone 
around who can either explain things to you or point you to 
someone else who can. They can in turn provide you with the 
various documents (called RFCs, for Request For Comment) which 
describe Internet addressing, standards for the exchange of 
Internet mail and network news, etc. 

(You can also obtain these by buying them from the Network 
Information Center at SRI International in Palo Alto, CA, but I 
do not have a complete list of the applicable documents yet, and 
you do not want to buy [let alone read] all of the available 
RFCs. Next month's article will have a list of the RFCs to 
order, along with complete ordering information.) 
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If you can't find a local Internet guru, don't despair: One of 
the things our Working Group is going to do is collect all of 
the necessary information and boil it down into easily-digested 
form. There's no need for more than the first few sites to dig 
it out ourselves! But if you want to be one of the first few 
sites, you'll need to know this material. (Then I can ask you 
questions.) 


Acquire Hardware 


You'll need, at minimum, a 1200 or 2400 bps autodialing modem, 
attached to your VAX in such a way that software in the VAX can 
place outgoing calls, and incoming callers can be connected to 
your VAX. For traditional terminal multiplexers this means 
connecting the modem to a port that supports modem control (e.g. 
not ports 2 through 7 of a DMF32) . I don't know what it means 
for ports on Ethernet terminal servers, since we don't have any 
here and I don't know how they work for outgoing calls. (I do 
know that PMDF can negotiate the terminal server connection 
sequence for an incoming call; this would also work for modems 
attached to port selectors and the like.) 

Oh, yes — order a phone line, preferably one that does not go 
through your company's PBX or Centrex or equivalent, and 
certainly not one that requires an operator to connect it to the 
VAX. Use it for a while with the modem and have the phone 
company correct any line noise problems before it's time to 
connect to the network. 

If you already have a suitable modem on your VAX, perhaps to 
support logins-from-home by employees or students at home, you 
can use that for PMDF links. Don't worry about interference 
with dialup terminal users: PMDF can be told to only place 
calls during hours when no one else will likely want the line, 
and if it finds the line in use (either when attempting to place 
an outgoing call or when calling into another system) , it will 
just try again later. 


Talk To Your Management 


Obviously you're going to be spending some money for phone 
lines, line charges, disk space, etc. You will also be making 
known, to people at another site, a telephone number and 
username/password which can be used to access your VMS system. 
Granted the username will be a captive account, good only for 
sending and receiving mail via PMDF (the news traffic will be 
sent as "mail"); granted that there are thousands of Unix sites 
all around the country doing the same thing with uucp-captive 
accounts; you may still find it difficult to convince management 
that this is a good idea. (I don't know if dialback schemes 
will be usable with PMDF.) 

But convince them you must, if you want to join the network. 
Things will become easier after the network actually exists and 
has a few hundred sites on it; there will be a snowball effect 
once "everyone is doing it". But for the first hundred or so, 
things will be tough. Better start working on the problem now. 
(If all else fails, go to work for a more reasonable outfit.) 


Find Potential Network Partners 


Find other sites in your area to hook up to. In addition to VMS 
sites, you want to find a Unix site that is running Berkeley 
4.3; they should have the MMDF software, and can therefore 
provide a gateway for you to the existing Unix-based network. 
(Whether they'll be willing to do so is another issue.) 

(Of course, if you have a Usenet-connected machine running 4.3 
in your computer room, that problem is solved, but you should 
still look for other potential VMS sites in your area; if we're 
at all successful, they'll be wanting to connect to you.) 


Write To Me 


To build a reasonable network in as short a time as possible, we 
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must hear from as many interested sites as possible. We need 
the following information: 

o Name, address, phone, etc. If you have any sort of 
electronic addresses (whether on networks or on dial-in 
machines like CompuServe), include those. 

o Do you think your site will be able to place and/or 
receive local and/or long distance telephone calls, in 
order to exchange mail and/or news with other sites? 
What do you think the cutoff point might be in terms of 
dollars per month? 

o Are any systems at your site connected to any part of 
Internet? (In the United States, Internet includes 
Arpanet, Milnet [but we can't use that], Bitnet, CSNET, 
and UUCP.) 

o Are you willing to be a pioneer, or would you prefer 
not to hook up to us until we have everything working 
reliably? 

o Does your company operate any long-distance VMS-to-VMS 
DECnet leased lines, whose excess (e.g. late-night) 
capacity might be used for mail and/or news? 

o . . .anything else you think might be useful for us to 
know. 


Simpact Associates 
9210 Sky Park Court 
San Diego, CA 92123 
619-565-1865 


uucp: 
arpa: 
internet: 
or: 

US194066 on 
DECUServe: 


{akgua,hplabs!hp-sdd,sdcsvax,nose}!crashIpnetOl!jeh 

crashlpnetOl!jeh@nosc.mil 

jeh@pnet01.CTS.COM 

pnetOl!jeh@crash.CTS.COM 

the Pageswapper system (see page VAX-2) 

HANRAHAN 


NOTE: If you want to join the network, we want to hear from 
you, whether or not you can place outgoing calls, provide DECnet 
link capacity, etc. 


Conclusion 


The light is (finally) visible at the end of the tunnel, and we 
are fairly certain that it's not a freight train. Right now it 
looks as though we might easily be up and running by the Fall 
Symposium in Anaheim. If you can help in any way, please let us 
know. 


Jamie Hanrahan 


VAX-30 


VAX-31 



PAGESWAPPER - August 1987 - Volume 9 Number 1 
INPUT/OUTPUT 


INPUT/OUTPUT 


A SIG Information Interchange 

A form for INPUT/OUTPUT submissions is available at the back of 
the issue. 

To register for on-line submission to the Pageswapper dial: 

(617) 262-6830 

(in the United States) using a 1200 baud modem and log in with 
the username PAGESWAPPER. 


Note 567.10 BACKUP Hints and Questions 10 of 13 

"Kevin Angley" 19 lines 27-MAY-1987 14:45 

-< To CRC or not to CRC >- 


The /CRC or /NOCRC question has taken pseudo-religious airs. At 
Nashville, top people in DEC'S storage group said that /CRC was 
a waste of time with new technology drives. However, the VMS 
Backup developer stressed the importance of reliability that a 
software CRC gives you. It comes down to the question of how 
far do you go in establishing a high confidence level. After 
all, you could do "paranoid" backups (small blocks, redundancy 
groups, /CRC, etc.) and THEN do fifty BACKUP/COMPARE' s if you 
wanted to be EXTRA sure. But there's a point of diminishing 
returns, isn't there? 

Key to this discussion is the number of times "block recovered 
by redundancy group" is actually due to a software CRC error, or 
by a hardware reported error. The VMS developer said that 9 
times out of 10 that you see that message, /CRC has saved you 
(seems unlikely to me) . But the same message is reported for 
hardware detected errors, so you cannot build any kind of 
historical feeling for this. Perhaps if backup gave you a clue 
as to whether the hardware was the reason for tossing a block, 
or if the software CRC helped out, then we could judge this 
issue better. 

Kevin Angley 
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3301 Terminal Drive 
Raleigh, NC 27604 
(919) 890-1416 


Note 567.11 BACKUP Hints and Questions 11 of 13 

"Linwood Ferguson" 24 lines 29-MAY-1987 21:08 

-< /CRC gets you $25,000+ TK50 >- 


/CRC and /NOCRC never seemed worth it, even for marginal gains 
on slow (i.e. 750 machines). Now it seems that it might be 
worth the risk: we tried our first MicroVax II with a TU81+. 

First experience, with our standard backups (/CRC by default) 
caused the language to singe the cabinet: it was as slow as a 
TK50; worse since you could see it sitting there and barely 
moving. Then I tried /NOCRC and no other changes (65534 blocks, 
/buff=5) and the tape streams at 75 ips with no stops (well, 
almost none depending on what it's copying). It is visibly the 
same speed as a 8500 we use (/CRC there). Actual timing put 
elapsed time "cost" of /CRC at 518% and CPU time cost at 1600%. 
CPU and elapsed were almost identical (does this make it a "reel 
time" backup?). 

So, for the moment, rather than tell the people paying the bill 
that they paid $25,000+ for a TK50, we're going with /NOCRC and 
crossing our fingers, and /VERIFY'ng more often. 

Question: can someone enlighten us as to whether there is such 
a thing as redundancy groups if you use /NOCRC, or what effect 
/GROUP has if you use /NOCRC? The manual seems to disconnect 
these somewhat. Is there any way to put redundancy into the 
backup without /CRC? 

Linwood Ferguson 
MJ Systems, Inc. 

P.O. Box 5223 

2564 Ivy Road (22901) 

Charlottesville, Va. 22905-0223 
804/977-2732 


VAX-33 













PAGESWAPPER - August 1987 - Volume 9 Number 1 
INPUT/OUTPUT 


PAGESWAPPER - August 1987 - Volume 9 Number 1 

INPUT/OUTPUT 


Note 567.13 BACKUP Hints and Questions 13 of 13 

"Frank J. Nagy" 12 lines l-JUN-1987 08:48 

-< /GROUP and /CRC are indeed different >- 


The redundancy group (/GROUP) and cyclic redundancy (/CRC) are 
indeed separate. The redundancy group, according to the 
documentation, is a complete XOR block written every N blocks. 
That is, it seems to be the XOR of the previous N blocks. The 
redundancy group allows BACKUP to recover a block from the group 
if it disappears or is unreadable by using the other N-l blocks 
of the group with the XOR block. Or, at least that seems to be 
the theory. 

Personally, I think that /NOCRC is probably OK on 6250 bpi 
tapes. We plan to proceed in this fashion once we get a TU81 + 
for our LAVC. 

Frank J. Nagy 
Fermilab 

PO Box 500 MS/220 
Batavia, IL 60510 
(312)840-4935 


Note 577.18 Questions/Comments on TPU 18 of 18 

"Offline Submission" 72 lines 29-JUN-1987 22:06 

-< Customization in Germany >- 


I am the leader of a software development group and we used a 
number of editors in the past. Getting our first VAX with EDT 
in 1983, it was our first full screen editor and all our people 
loved to work with it. 

But then came EVE. It should be the best you ever got, but 
nobody on our team could/would use it, because the man/machine 
interface was quite different from our well known EDT. 

But there was a small example in the TPU manual to make EVE like 
EDT. With this example and some additional changes I tailored 
the keypad interface of EVE to an EDT-like keypad. My people 
now loved EVE and - with some experience - had the advantages of 
EVE too. 


One of the best features of TPU is that you can extend the 
functionality of the programs stepwise without changing the 
previous characteristics. So later I extended EVE by adding 
several functions: 

- First I added typewriter-like tabulator functions, which 
insert a number of spaces instead of tabs (to get a readable 
output on a standard printer), working in overstrike and insert 
mode. 

- The next step was to implement functions for the replacement 
of rectangular text blocks, also working in overstrike/insert 
mode. 

- Then I included paragraph formating tools with semi-automatic 
hyphenation and right margin justification. 

- Then I added tools for pagination. 

- And last but not least I added tools for setting up tables of 
contents and indices. 

Finally we got a very powerful online text processing system. 
For our standard technical paper it fits our requirements on a 
WYSIWYG editor and nobody in our group will use the 
old-fashioned Runoff anymore. More and more of our marketing 
and management people will use this powerful and easy to use 
tool. 

But against all its advantages, TPU has sometimes mysterious and 
strange behaviour. In particular the pattern and search 
functions deliver sometimes unexpected results. We discovered a 
number of faults, and if you write a letter to the source you 
will get an answer like: 

"Thank you for bringing this to our attention. You are right... 
We plan to fix this problem in a future release of TPU." 

Some of the problems we encountered could have been prevented by 
better documentation, particularly in the case of side effects 
of the predeclared functions which are not explained (with some 
exceptions). 
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If there is any interest in our text processing package we can 
hand it out. Unfortunately the program and the documentation is 
written in German (procedure names and messages) and probably 
someone would have to translate it. 

Rudolf Reusch 

AEG Aktiengesellschaft 

A46 V42 

Hafenstr. 32 

D 2000 Wedel/Germany 

Telephone: (0)40-700-565 

Date: May 22, 1987 


Note 585.8 Anyone use defrag programs? 8 of 10 

"Kevin Angley" 15 lines 27-MAY-1987 14:56 

-< Defrag alternatives >- 


For sites that do not have much utilization during the wee 
hours, I suggest compressing as part of a nightly backup. We do 
an image backup of one of the user disks each night to a scratch 
disk. Then, if NO errors occur during that image backup (and be 
careful - backup's $SEVERITY is not to be trusted), we dismount 
the subject disk, and do a physical backup back to it. Then, we 
write the scratch disk off to tape. 

Now if RA's had programmable unit plugs, you wouldn't even have 
to do that. 

As far as third party defraggers go, I prefer to hold off for a 
year or two. I heard at Nashville that defrag tools are on 
DEC'S possible do list for some possible unannounced release 
AFTER the next major unannounced not to be mentioned release. 

Kevin Angley 
3301 Terminal Drive 
Raleigh, NC 27604 
(919) 890-1416 
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Note 585.9 Anyone use defrag programs? 9 of 10 

"Ken A L Coar" 12 lines 28-MAY-1987 11:47 

-< Ah'm agin 'em >- 


My personal opinion is that I don't want to TOUCH a third-party 
defragmentation program until the people who DESIGNED the file 
system have come up with one. This item has been high on the 
SIR list for a long time, as I recall, and if Digital hasn't 
done it, I surely don't want to trust my file systems to someone 
else's original code..! Particularly since the license would 
almost certainly read 'no liability is assumed for loss or 
damage to ANYthing - data, files, business revenues, your 
hairline or hair colour - stemming from your use of this 
product.' If something goes dreadfully wrong, I want someone I 
can jump upon with hobnailed boots! :-)} 

#k 

Ken A L Coar 
General Dynamics 
Office Systems 

12101 Woodcrest Executive Drive 
Creve Coeur, MO 63141 
(314) 851.4003 (CST) 


Note 585.10 Anyone use defrag programs? 10 of 10 

"Brian Tillman, Lear Siegler, Inc." 4 lines 24-JUN-1987 10:43 
-< I'd love a defragger, but... >- 


The problem I've encountered is that, try as I might, I can't 
justify the cost to management, because I can't get a handle on 
how much money I'm losing because of decreased throughput. 
Inefficiency due to fragmentation is extremely intangible. 

Brian Tillman 
Lear Siegler, Inc. 

4141 Eastern Ave. MS121 
Grand Rapids, MI 49518-8727 
(616)241-8425 


VAX-37 















PAGESWAPPER - August 1987 - Volume 9 Number 1 
INPUT/OUTPUT 


PAGESWAPPER - August 1987 - Volume 9 Number 1 

INPUT/OUTPUT 


Note 590.5 VAX 11/750 Word Processor 5 of 7 

"Bob Ainsley" 12 lines 4-JUN-1987 14:32 

-< MASS-11 Experience >- 


We are using MASS-11 on 2 clusters with CPUs ranging from 750 to 
8600. MASS-11 is a memory hog. It can be a CPU hog if 

something like a table of contents is requested. 15 to 20 users 
can bring a 780 to its knees. SPM and VPA seem to confirm that 
memory is more critical than CPU. We usually see 85-90% of 16 
megs memory used on a dedicated 780 while CPU will be around 
50%. Adding more memory (8 megs) seems to help. 

There is one bug that we can't seem to isolate. MASS-11 will 
sometimes go off into the weeds and get stuck in an infinite 
loop, consuming as much CPU that is available. The only 

recovery is stopping the offending process. 

Bob Ainsley 
DSC COMMUNICATIONS 
1000 COIT RD 
PLANO TX 75075 
2145193952 


Note 590.6 VAX 11/750 Word Processor 6 of 7 

"Barry L. Wallis" 13 lines 4-JUN-1987 19:04 

-< More MASS-11 experience. >- 


We also use MASS-11. We use it on a VAX-8600 with 20 megs of 
memory. I concur that memory seems to be the critical element 
(most processes seem to ring in between 1900 and 2000 pages 
[2000 pages is our WSQUOTA is 2000]). 

The only complaint I have is when one of my users does a large 
match/merge operation (to produce 5000 "personalized" form 
letters) . At that point page faults so badly that I need to 
suspend until non-prime time so my other users can get useful 
work done! 


But all told, I would pick MASS-11 (over WPS and other word 
processors) again. 

Barry L. Wallis 
Fleetwood Enterprises, Inc. 

3125 Myers Street 
Riverside, CA 92523 
(714)351-3682 


Note 590.7 
"John Osudar 


VAX 11/750 Word Processor 
12 lines 

-< Another MASS-11 site >- 


7 of 7 
4-JUN-1987 20:21 


We use MASS-11 on a 785 with 32 megs, and a lot of other 
(interactive and batch) activity. I wonder if you've got the 
image installed shareable? The current version (6C), when 
installed, shows up as global sections totalling 715 pages. 
MASS-11 MAIL (if you use it) installs at another 616 pages. 
That 715 figure is for the "large" (monolithic) image. I agree 
that MASS-11 can be a memory hog, and especially a CPU hog, 
particularly when doing formatting for printing. The "infinite 
loop" problem that someone mentioned is a bug that we also saw, 
though I believe it was in a version before the current one. If 
you can feed MASS-11 the memory and cycles, though, it's a good 
product — both our secretarial personnel and scientific staff 
use it. 

John Osudar 

Argonne National Laboratory 
9700 S. Cass Ave. 

Bldg. 205 A-051 
Argonne, IL 60439-4837 
(312) 972-7505 
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Note 599.7 Any PSI users out there? 7 of 9 

"Ralph Sierra" 9 lines 7-JUN-1987 17:32 

-< Should I be using PSI? >- 


This may be a naive question but here goes (just charge me 5 
negative points): What is PSI? 

Reply .6 said they were using PSI in a 'classic' application, 
for communicating via TYMNET. I have a user that calls various 
information services, in some cases, via TYMNET. This user is 
currently dialing out using VAXNET. How would this differ from 
using PSI? 

Ralph Sierra 

NKF ENGINEERING INC 

12200 SUNRISE VALLEY DRIVE 

RESTON VA 22091 

703/620-0900 


Note 599.8 Any PSI users out there? 8 of 9 

"Jamie Hanrahan" 118 lines 8-JUN-1987 15:33 

-< PSI explained in a (large) nutshell >- 


> What is PSI? 

PSI (technically, "VAX-11 PSI") is a layered product from DEC 
that allows VMS to access packet-switched data networks (PSDNs). 

If you're familiar with PSDNs, skip ahead to the section 
labelled "WHAT PSI DOES". (Difficult to do with NOTES, I 
know...) 

ABOUT PSDNs 

Without going into the details of packet switching, suffice it 
to say that, for the most part, a packet-switched data network 
is a privately-owned nationwide data communications network. 
The best- known examples in the US are Telenet and Tymnet. (In 
most other countries there is just one PSDN, and like the phone 
systems, they are run by each country's telephone and postal 
authority. Also, there are such things as private PSDNs, 


operated by and for a single company.) A PSDN allows you to 
connect multiple systems at various sites around the country or 
the world. Depending on the amount of traffic and the number of 
connections you need, there can be a large cost savings over 
leased lines. 

Suppose you have systems in Boston, Los Angeles, Seattle, and 
Houston, and you want each connected to all the others. You 
would need six long-distance leased lines. Or, you could sign 
up with a PSDN. A leased line runs from each system to one of 
the PSDN's nearby switches (four lines total). Each of your 
systems is assigned an "address" by the PSDN, quite analogous to 
a phone number. When one system wants to talk to one of the 
others, software in the first tells the PSDN to place a "call" 
over the PSDN to the target system's address. When the target 
system answers ("confirms the call"), the two systems can 
communicate just as if there was a leased line between them. 
Naturally you can set things up so that your system will only 
accept calls from certain other addresses (presumably the 
addresses of your other sites). 

Multiple calls can be multiplexed over a single connection to 
the PSDN, so all systems can be simultaneously connected to all 
others (within reason; there are some large limits on the number 
of simultaneous calls) with just one local leased line per 
system. 

Charges: You pay for the local leased lines, plus a monthly 
service fee, plus a charge for the amount of data (actually, the 
number of packets) you send. None of the charges are related to 
the distances between systems. The rate structures are such 
that if you have several sites to be connected, and you wouldn't 
use a leased line to more than, say, 10% capacity (remember this 
includes evening and weekends, during which time many leased 
lines are idle), you may well save money by using a PSDN. If 
you have just two systems to connect you may find that the cost 
of the single long-distance leased line is less than the cost of 
the two local leased lines plus the PSDN's monthly fees. (That 
was our experience.) 

Another use for a PSDN is to support people calling into your 
system with async terminals from around the country. You can 
set up a bunch of modems and let them make long-distance calls; 
or, you can hook up to a PSDN. Instead of calling your system 
directly they call a (usually) local number for the PSDN's 
nearby "X.29 PAD” (Packet Assembler/Disassembler). They then 
tell the PAD (via their terminal keyboard) the PSDN address of 
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your machine. The PAD places a PSDN "call" to your machine, and 
software in your machine creates a virtual terminal, much like a 
DECnet remote terminal, in response to this call. You (not the 
caller) pay for line time on the PAD, plus (I believe) a charge 
for the amount of data. This is much cheaper than the 
equivalent long-distance phone line time would be, for almost 
any distance, and line errors are confined to the hop from the 
caller s modem to her local PAD (everything else is checksummed 
and corrected if errors are noted) . The downside is that the 
round-trip time is considerably longer than for a regular dialup 
connection; use of things like screen editors, which require 
fast response to individual keystrokes, is severely hampered. 

WHAT PSI DOES 

VAX-11 PSI provides the software to place and accept calls and 
otherwise speak the proper protocol (X.25 over HDLC) to the 
PSDN. PSI provides four interfaces to users and programmers: 

1. A $QIO interface for programmers, quite similar in function 
(though, of course, different in detail) to the $QIO interface 
for DECnet task-to-task communication. Processes on VAXes 
connected to the PSDN can communicate by using this feature of 
PSI. No other software (e.g. DECnet) is required. 

2. X*29 (remote terminal) support. PSI can accept "calls" from 
PADS, allowing remote terminal users to connect to your system 
via the PSDN. A.user logged into your system (usually locally, 
but not necessarily) can also place ^outgoing* "remote terminal" 
calls to *other* systems on the PSDN (assuming that those 
systems have X.29 remote terminal support). 

3. PSI MAIL. Users on machines connected to a PSDN can use VMS 
MAIL to send messages to each other, again without needincr 
DECnet. 

4. DECnet data link mapping (DLM) . If you have DECnet and PSI 
on systems that are connected to a PSDN, DECnet can place PSDN 
"calls" between the systems. (The name "data link mapping" 
refers to the idea that the software "maps" a PSDN "call", or 
"virtual circuit" (a requested and confirmed call creates a 
virtual circuit), into a DECnet data link.) Then DECnet can use 
the data link for all the usual DECnet stuff: Task-to-task 
communications, file transfers, remote terminals, VMS MAIL, 
etc., etc. 


Naturally, all of the above traffic can ride on the single 
leased line between your system and the PSDN's local switch. 

Does that help? 

(Experts: What have I missed or gotten wrong?) 

Jamie Hanrahan 
Simpact Associates 
9210 Sky Park Court 
San Diego, CA 92123 
619-565-1865 


Note 599.9 Any PSI users out there? 9 of 9 

"Jamie Hanrahan" 29 lines 8-JUN-1987 15:53 

-< PSI vs. VAXNET? >- 


Oops, almost forgot your other question: 

I have a user that calls various information services, 
in some cases, via TYMNET. This user is currently 
dialing out using VAXNET. How would this differ from 
using PSI? 

Right now your user is, presumably, using VAXNET* to dial out to 
TYMNET'S nearby (I hope it's nearby) X.29 PAD. If you connect 
your VAX to TYMNET and install PSI (and there's no point in 
doing one without the other), your user could do this instead: 

$ SET HOST/X.29 other_system_name_or_psdn_address 

Benefits would be immunity from line noise (since every serial 
link is now a checksummed-and-corrected link) and, possibly, 
greater effective line speed, as the local hops to the PSDN 
switches are generally 9600 bps or more. But the cost would be 
exorbitant if this was all you were doing with the PSDN 
connection. 


* (Footnotes in NOTES? Oh, well) Someone is sure to ask about 
VAXNET. VAXNET is a package that has appeared on several DECUS 
VAX SIG tapes. It is a very, very fancy SET HOST utility that 
includes autodialing capability for various modems, file 
transfer support, and many other features. It is quite a bit 
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more efficient than the regular VMS SET HOST, according to 
reports. 

Jamie Hanrahan 
Simpact Associates 
9210 Sky Park Court 
San Diego, CA 92123 
619-565-1865 


Note 637.1 New Version of MRGATE 1 of 2 

"Ken A L Coar" 13 lines 28-MAY-1987 10:42 

-< Not quite, for us at least >- 


Another neat thing to do with MRGATE is to have your 
VMSmail automatically sent to ALL-IN-1 ! ! You can do 
this by setting the VMSmail forwarding address to 

Al_user::A1::MRGATE 

That doesn't work for us, because our ALL-IN-1 usernames are of 
the form 'lname,xx' (mine, for example, is COAR, KA) . In order 
to get this to work, we use 

MRGATE: : "Al: :alusername” e.g., MRGATE: : "A1: :COAR, KA" 

#k 

Ken A L Coar 
General Dynamics 
Office Systems 

12101 Woodcrest Executive Drive 
Creve Coeur, MO 63141 
(314) 851.4003 (CST) 


VAX-44 


PAGESWAPPER - August 1987 - Volume 9 Number 1 

INPUT/OUTPUT 


Note 637.2 New Version of MRGATE 2 of 2 

"Jack Patteeuw" 13 lines l-JUN-1987 06:52 

-< MAILUAF.COM Warning ! >- 


Ken is very much correct ! In fact we have a Al node on our 
network that assigning ALL-IN-1 user names in the format "Lname, 
Fname". Note the SPACE in between ! 

Just a warning for all you "System Manglers" out there. If you 
try and use MAILUAF.COM to set another users autoforward address 
be warned that the quotes used in .1 will screw up the database. 

This has to do with the way the .COM file re-builds the record 
to be written out to MAILUAF.DAT. Best protection is to double 
check the entry with a SHOW command. If it is screwed up, you 
will have to log into that account and fix via MAIL or fix the 
.COM file to properly handle the quotes (which I have not had 
time to do yet). 

Jack Patteeuw 
Ford Motor Co. 

Electrical and Electronics Division 
31630 Wyoming 
Livonia, MI 48150 
313-323-8643 


Note 642.5 print&batch complaints 5 of 10 

"Brian Tillman" 12 lines 24-JUN-1987 09:33 

-< On the whole, they seem to work >- 


RE: < Note 642.0 by NODE::US133673 "John Osudar" > 

As long as we're complaining about the queue manager/job 
controller/symbionts (e.g. note 630)... 

We find the Separation modules and the Setup modules generally 
work well. However, I do have to disagree with the form-level 
setup module. It comes out in front of every file in a job, not 
just when the form is changed, which seems to me to be all 
that's necessary. Notes 619 et. al. also address this issue 
for non-DEC lasers, which fits us as well. 


VAX-45 













PAGESWAPPER - August 1987 - Volume 9 Number 1 
INPUT/OUTPUT 


Brian Tillman 
Lear Siegler, Inc. 

4141 Eastern Ave. MS121 
Grand Rapids, MI 49518-8727 
(616)241-8425 


Note 642.6 print&batch complaints 6 of 10 

"Tony Carter" 4 lines 25-JUN-1987 07:39 

-< Form-level setup modules useful >- 


We use form-level setup modules with our LN03's. The setup 
module resets the laser printer to a known state. We had users 
changing all sorts of printer parameters and not resetting after 
they were done. This way it is transparent to the users. 

Tony Carter 
P.O. Box 846 
Middleton, MA 01949 
(617) 245-6600 


Note 642.7 print&batch complaints 7 Q f 10 

"John Osudar" 6 lines 25-JUN-1987 15:57 

-< re: 642.6 >- 


That s what job reset modules" are for — to reset your printer 
to a known state after a job finishes. The form-level stuff in 
intended to set up new characteristics specific to the form 
being used. While you can obviously put things anywhere you 
want, it's a lot easier to put reset stuff in the job reset 
modules, setup stuff in the setup modules, etc. 

John Osudar 

Argonne National Laboratory 
9700 S. Cass Ave. 

Bldg. 205 A-051 
Argonne, IL 60439-4837 
(312) 972-7505 
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Note 642.8 print&batch complaints 8 of 10 

"Tony Carter" 6 lines 26-JUN-1987 08:02 

-< Re: 642.7 >- 


Using "job reset modules" is fine if you know that all files in 
one job are to be printed with the same characteristics. But if 

one file is to be printed in 132 columns and another in 80 

columns then it is not good enough. Though your point is well 

taken. It may be worth putting up with that problem to put 

things where they really belong. I'll check it out. 

Tony Carter 
P.O. Box 846 
Middleton, MA 01949 
(617) 245-6600 


Note 642.9 print&batch complaints 9 of 10 

"Tony Carter" 4 lines 28-JUN-1987 12:38 

-< Form-level modules vs Job reset modules >- 


Using the LN03 reset escape sequence in the job reset module 
causes an extra page to be ejected. Using it in the form-level 
module works fine. There may be a work around for this, but I 
haven't figured it out yet. 

Tony Carter 
P.O. Box 846 
Middleton, MA 01949 
(617) 245-6600 
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Note 642.10 print&batch complaints 10 of 10 

"Chris Erskine" 7 lines 29-JUN-1987 12:17 

-< Repeat of how to eliminate the extra pages >- 


A repeat of replies from myself and others. By putting a <FF> 
on the first line of the RESET module with escape sequences also 
on the first line appears to fix the problem. I have run this 
on an LN03 without problem but have not been back to my other 
site to test on an LN01 but I think the extra page is from the 
spooler so the type of printer should not matter. 

Chris Erskine 
6001 Adams Rd. 

Bloomfield Hills, MI 48013 
(313) 258-4049 


Note 644.15 Wanted: MAIL improvements 15 of 18 

"John Osudar" 20 lines 4-JUN-1987 20:37 

-< another wish list item >- 


Just to add to my previous list of desired improvements: VMS 
MAIL lets you SET FORWARD your mail -- and this is great, since 
I have accounts on four or five different VAXes located in 
different places. However, automatic forwarding could be 
better: first of all, it ought to be trivial for MAIL to 
continue to broadcast a message telling me (if I'm logged in, of 
course) that someone just sent me mail on node ABC, even though 
that mail was forwarded to node XYZ as I directed. (In fact, it 
should be easy to remind me at the same time that the forwarding 
actually happened!) This would be a low-cost feature that would 
help users get more timely notification of their messages, and 
can be disabled by any user that doesn't want it. The other 
thing I don't like about forwarding probably can't be fixed 
without store-and-forward, which I don't think belongs in the 
basic VMS MAIL (although I wouldn't complain if someone gave it 
to me!) — and that is the problem that, if the node to which 
your mail is forwarded can't be reached, the message is lost. 
This can be really confusing for someone who thinks they're 
sending a local mail message and is told that the node is 
unreachable. However, as I said before, I don't expect an easy 
fix for this one... 
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John Osudar 

Argonne National Laboratory 
9700 S. Cass Ave. 

Bldg. 205 A-051 
Argonne, IL 60439-4837 
(312) 972-7505 


Note 644.16 Wanted: MAIL improvements 16 of 18 

"Jamie Hanrahan" 15 lines 8-JUN-1987 14:37 

-< PMDF can do store-and-forward >- 


You can get store-and-forward for VMS mail at low cost by using 
PMDF (Pascal Memo Distribution Facility). PMDF is also the 
transport mechanism we've selected for the "VMS User's Network" 
(formerly Usenet-for-VMS; see note 511), so if you're interested 
in that you need PMDF anyway. To get PMDF, send $50 to: 

Ned Freed 
The PMDF Project 
Computing Services 
Harvey Mudd College 
Claremont, CA 91711 

It comes on a magtape with all sources, doc. as .RNO and .MEM 
files, and hardcopy documentation as well. Highly recommended. 

Jamie Hanrahan 
Simpact Associates 
9210 Sky Park Court 
San Diego, CA 92123 
619-565-1865 
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Note 660.0 Applications software standards 26 replies 

"Kevin Angley" 70 lines 27-MAY-1987 15:05 


We are in the process of putting together an "applications 
software" standard which we will at least try to get third party 
software suppliers to adhere to. I am putting it in this forum 
to generate some discussion: Are these reasonable/practical? 
Can you think of other standards? Here is the condensed first 
draft: 

Most writers of application software develop their application 
and installation procedures with the naive notion that their 
package is the only package to run on the system. They make 
assumptions about the practicality of "system" level 
modifications, logical names, and privilege. Because we must 
maintain multiple applications, often for similar purposes, and 
because many applications are actually used by a small 
percentage of the user population, it is mandatory for us to 
provide support/changes to a user's process for a particular 
application only if that user is going to use that application. 
This means that all logicals, verb definitions, symbols, etc. 
will be done on a per process basis, upon the user's request. 
We have implemented a "SUPPORT" command procedure which does the 
necessary setup for each application. 

The application software standards follow. In some cases, minor 
exceptions can be made as long as the vendor is willing to 
cooperate in providing the software support necessary to comply 
with the intent, if not the letter of the standards. VMS and 
layered products from Digital are exempt. 

o Command verbs will be added on a per process basis via 
SET COMMAND'S rather than modification of the 
network-wide DCLTABLES. 

o Symbol definitions will not be made in the cluster-wide 
SYLOGIN.COM. Rather, symbol definitions can be made in 
the application setup command procedure or in command 
procedure(s) nested in the application setup command 
procedure. 


o 


Logical names may be entered only in the process 
tables. Group and system logical name tables, or 
user-created logical name tables which require 
privileges to create cannot be used. 


o The application software must reside in directories of 
its own, and may not place any files m "system 
directories", including SYS$SYSTEM, SYS$HELP, 


o Applications may not depend on users having privileges 
beyond TMPMBX and NETMBX. 

o Applications may not require that images be installed 
with any privileges. Exceptions may be made for images 
that require privilege to interact with dedicated 
hardware (e.g. a device driver for a graphics 
station). In these exception cases, source, code must 
be provided, and the image built from this source at 
our site. 


o Logical names must be of the form "xxx_name" where xxx 
is a unique vendor designation, the underscore must.be 
present, and name is any acceptable name not containing 

" $ " . 

o Magnetic tape written in VMS "backup" format (either 
6250 or 1600 BPI) is the preferred distribution media. 
Files-11 formatted tapes, TK50 tape cartridges, or RX50 
diskettes may also be acceptable. Distribution media 
are kept onsite as long as they are current level, and 
will thereafter be destroyed if requested by the 
vendor. We do not return media to the vendor under any 
circumstances. 


Kevin Angley 
3301 Terminal Drive 
Raleigh, NC 27604 
(919) 890-1416 


To be continued in next issue . - - 
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DECUS PROGRAM LIBRARY 


NEW LIBRARY PROGRAMS AVAILABLE 
FOR THE 

VAX/VMS FAMILY OF COMPUTERS 


DECUS NO: V-SP-62 Title: PC SIG Tape Copy Version: 
May 1987 

Author: Various 

Submitted by: Fritz Howard Operating System: MS/ 
DOS V2.ll Source Language: C, TURBO PASCAL 
Memory Required: 256KW Software Required: KER- 
MIT Keywords: Utilities - MS/DOS 

Abstract: With these programs you can use your com¬ 
puter to create the ultimate desktop. All of the programs 
have been tested and work on the machine noted. Where 
an author requests certain restrictions be observed, 
DECUS nor I take any responsibility. It is your responsi¬ 
bility to follow the authors’ instructions. 

To use: Transfer to your PC using KERMIT or some 
other file transfer protocol. DO NOT use VAX/VMS Ser¬ 
vices or DECnet DOS as these files were uploaded to a 
VAX using Kermit. Unarchive using ARC520.COM, and 
have fun. 


Some of the programs included are: 


CALRB.ARC 

HMS.ARC 

MACPIX.ARC 

MLRB.ARC 

RBE.ARC 

RX50.ARC 

TIMER.ARC 


Calendar manager (appointments, etc) 
uses windows. 

Home Management System for the 
Rainbow. 

Make your Rainbow look like a Mac. 
Fool your friends. 

Mailing List program. Maintain a mail 
list. V2.3. 

Rainbow Emulator for the IBM. Run 
Rainbow programs. 

Read/write Rainbow RX50 diskettes 
on a PC/AT. 

Constant clock in the corner of your 
screen. 


Notes: Operating system MS/DOS V2.ll or higher re¬ 
quired. 

Complete sources not included. 

Media (Service Charge Code): 600’ Magnetic Tape(MA) 
Format: VMS/BACKUP 


DECUS NO: V-SP-63 Title: Miscellaneous PC Tool 
Collection # 1 Version: VI, May 1987 

Submitted by: Glenn Everhart, Ph.D. Operating System: 
MS/DOS, OTHER, VAX/VMS Source Language: C, 
FORTRAN 77, FORTRAN IV, PASCAL Keywords: 
Editors, Spreadsheet 


Abstract: This tape contains a variety of tools mostly for 
the MS-DOS environment, plus a few for VMS and for 
Amiga. These represent tools obtained from public domain 
sources other than the PC-SIG, and hence do not properly 
belong in the “PC-8088 Collections”. Many of these pro¬ 
grams originate in the PC-Blue Library and include a 
huge grab bag of MS-DOS utilities. Also present is Micro 
GNU Emacs Version lb complete, including VMS, MS- 
DOS, AmigaDos, and other versions. 

The Amiga utilities are a “core functionality” set per¬ 
mitting an Amiga to become an inexpensive 3D CAD/ 
graphics workstation in a mixed environment, offering 
multitasking, VT100, TEK 4010, and other terminal 
frontends, and 704 by 470 pixel graphics resolution with 
up to 4096 colors at a time. 

AAAFILES.TXT files in the major directories give further 
information on particular files. 

Complete sources not included. 

Media (Service Charge Code): 2400’ Magnetic Tape 
(PA) Format: VMS/BACKUP 

DECUS NO: VAX-255 Title: JMU Utility Programs 
Version: V1.0, April 1987 

Submitted by: Mike O’Neill, James Madison University, 
Harrisonburg, VA Operating System: VAX/VMS V4.4 
Source Language: VAX-11 FORTRAN Software Re¬ 
quired: FMS Hardware Required: VT100 or emulator 
Keywords: Bulletin Board, Calculators, Mail, Utilities - 
VMS 

Abstract This submission consists of three utility pro¬ 
grams in use at James Madison University. They consist 
of an FMS based Bulletin Board System, an FMS based 
calculator program that uses the VT keypad, and a 
checkmail utility that allows you to check to see if some¬ 
one has read a mail message that you sent to them. We 
are currently running these programs on a cluster con¬ 
sisting of an 8650, 11/785, and 11/780 with common 
sysuaf, netuaf, and vmsmail files. 

The bulletin board system is a graphics based menu 
driven bulletin board that utilizes the cursor keys and 
return key for command selection. It features online help, 
multiple categories, tracking of unread notices, internal 
access to mail and the edt editor, automatic identification 
of notice owners, and automatic notice expiration. 

The calculator program utilizes the VT keypad to pro¬ 
vide a four function calculator with memory. It requires 
FMS to operate. 

The mailcheck program allows a user to check to see if 
someone has read a mail message that they had sent. It 
lists notice dates and subjects for all unread notices sent 


from the person running the program to the person being 
inquired about. This version also supports a cluster en¬ 
vironment with common sysuaf and vmsmail files. 

Notes: Operating system VMS 4.0 or later required. 

Media (Service Charge Code): 600’ Magnetic Tape (MA) 
Format: VMS/BACKUP 

DECUS NO: VAX-257 Title: Performance Monitoring 
Tools Version: V1.0, May 1987 

Submitted by: John F. Priebe, Edison State College, 
Piqua, OH Operating System: VAX/VMS V4.4 Source 
Language: DCL, VAX FORTRAN Keywords: Accounting 
Abstract: This submission contains performance moni¬ 
toring tools used for tuning VAX systems and extensive 
notes on how to use the tools for tuning. Included are 
DCL command files to automatical ly run the MONITOR 
utility every day, produce reports from the ACCOUNT¬ 
ING utility, and a program written in both DCL and 
FORTRAN which lists the images being run by all users 
of the system. 

Media (Service Charge Code): 600’ Magnetic Tape(MA) 
Format: VMS/BACKUP 


DECUS NO: VAX-258 Title: KILL Version: April 
1987 

Submitted by: Connie R. Minnick, James Madison Uni¬ 
versity, Harrisonburg, VA Operating System: VAX/ 
VMS V4.4 Source Language: VAX-11 FORTRAN Soft¬ 
ware Required: VAX/FMS- Forms Management System 
Keywords: Utilities - VMS 

Abstract: This is a program designed to enable an oper¬ 
ator or privileged user to affect another process on the 
system without having to look up and use the process 
PID. The only requirement to execute this program is 
that VAX FMS must be installed. 

FMS is used to set up a screen where the current pro¬ 
cesses will be displayed. The operator may then use the 
arrow keys to 

“scroll” through the processes and perform certain func¬ 
tions on the selected process. 

The process data information includes: 

USERNAME TERMINAL 

PROCESS NAME ACCUMULATED CPU TIME 

PROCESS STATE PROCESS AGE or CONNECT 

TIME 

PROCESS TYPE 

The functions currently implemented are: 

ABORT ==} Aborts the selected process 

MONITOR ==} Monitors the selected process 

with SHOW PROC/CONTIN- 
UOUS 

TOPCPU ==} Displays the TOPCPU process¬ 

es on the system 


Other functions such as SUSPEND, RESUME and 
CHANGE PRIORITY can easily be built into this pro¬ 
gram as well. 

By default, all critical system processes will be filtered 
out and not displayed. This will avoid potentially aborting 
such processes. There are two arrays used for this pur¬ 
pose that should be modified for each application. One 
array lists the critical processes to be filtered and the 
other lists usernames for which you want to override the 
filtering procedure (i.e., users with SYSPRIV). 

Media (Service Charge Code): 600’ Magnetic Tape (MA) 
Format VMS/BACKUP 


DECUS NO: VAX-259 Title: MsglncVersion: V1.0 
Author: Donald R. Gummow, Monsanto Co, St Louis, 
MO 


Operating System: VAX/VMS V4.4 Source Language: 
VAX FORTRAN Keywords: Utilities - VMS 

Abstract: Msglnc is used to create include files from the 
object files produced by the VMS Message Utility. It 
supports C, FORTRAN and PASCAL, but you could 
always w T rite a new output routine if you want to support 
a new language. 

Some of the modules included on the tape are: 


Msglnc.for 

Msglnc.Table.cld 

Msglnc.KeyTable.mar 

Msglnc.Messages.msg 

LibForeign.mar 

LibParse.mar 
Str Length, mar 


The source code for the pro¬ 
gram. 

The CLD file that defines 
the command syntax. 

The MACRO that sets up 
the parse tables. 

Message Utility source. 
Utility to parse foreign DCL 
commands. 

Utility to do F$Parse stuff. 
Utility to get effective length 
of strings. 


Restrictions: Noted in documentation. 


Media (Service Charge Code): 600’ Magnetic Tape(MA) 
Format: VMS/BACKUP 


DECUS NO: VAX-261 Title: IdxTeX& GloTeX Version: 
V2.0, April 1987 

Author: Richard L. Aurbach, Monsanto Company, St 
Louis, MO 

Operating System: VAX/VMS V4.4 Source Language: C 
Software Required: LaTeX V2.09 

Abstract: The GloTeX program is used to automate the 
generation of a glossary in a LaTeX document. It uses 
the .glo file generated by the makeglossary command 
and one or more Glossary Definition Database Files to 
create a file which is input in the document to generate 
the glossary. 


LIB-1 


LIB-2 



The IdxTeX program is used to automate the generation 
of an index in a LaTeX document It uses the .IDX file 
generated by the makeindex command to create a file 
which is input in the document to generate the index. 

Version 2.0 improves the visual appearance of the index 
and adds support for page ranges, index cross references, 
and the genera tion of a master index. 

Media (Service Charge Code): User’s Manual (EA), 
600’ Magnetic Tape (MA) Format: VMS/BACKUP 

DECUS NO: VAX-264 Title: FEDT Version: May 
1987 

Submitted by: Jack Schwartz Operating System: VAX/ 
VMS V4.2 Source Language: MACRO-32 Software Re¬ 
quired: EDT Keywords: Editors 

Abstract: This program offers EDT under controlled 
higher process priority. Original priority is restored upon 
image termination. Much of the code deals with making 
sure original priority is restored when the image dies 
with an error condition. The program must either be 
installed with ALTPRI privilege or run from a process 
which has it 

The program takes advantage of calling EDT by allowing 
users to spawn a subprocess to execute another command 
without leaving the editor; the spawned process is at the 
original priority. The interface allows for both execution 
of single spawned commands and for spawning a new 
DCL shell from which several commands may be issued. 
The full EDT commandline is accepted by this program. 
LIB$TPARSE is used to parse the commandline input. A 
complete, unambiguous set of error messages is included 
in the program. 

The program also maintains the screen, clearing it when 
returning from spawned subprocesses and at image exit. 
It has separate scrolling reset capabilities for VT100 and 
VT200 series terminals. 

Restrictions: Must be installed with ALTPRI privilege 
or run from an account which has ALTPRI privilege. 
Program requires VMS Version 4.X or above for use of 
calling EDT. 

Documentation not available. 

Media (Service Charge Code): 600’ Magnetic Tape(MA) 
Format: VMS/BACKUP 


DECUS NO: VAX-265 Title: A Generic User Interface 
Version: 1A, May 1987 

Submitted by: Barry L. Wallis, Fleetwood Enterprises, 
Inc., Riverside, CA Operating System: VAX/VMS V4.1 
to V4.4 Source Language: VAX COBOL Memory Re¬ 
quired: Will run in a minimum configuration Software 
Required: SCOPE (can be changed to use other screen 
management systems). Keywords: Interface Routines, 
Utilities - VMS 


Abstract: The Generic User Interface (UIF) is a menu 

oriented user interface with the following features: 

. DCL procedures can be run interactively or in batch 
with any batch qualifiers. 

. Automatic parameter substitution and validation (for 
batch or interactive procedures). 

. Security by VAX USERNAME. 

. Tree structured menu system with multiple trees. 

. Non-menu shortcut method of executing procedures. 

. Can be run in captive mode. 

. Any DCL procedure (including any third party pack¬ 
ages or user written application) can be run. 

. A single VMS subprocess is reused for every active 
user (Le., two process slots are required for each user). 

These routines were described in the DECUS Symposium 

Session, “A Generic User Interface”, given at the Spring 

1986, Fall 1986, and Spring 1987 DECUS Symposia. 

Media (Service Charge Code): 600’ Magnetic Tape(MA) 

Format: VMS/BACKUP 


DECUS NO: VAX-266 Title: NO_FRAGMENTS, 

SMART and XMODEM__AU Version: 1.0, April 1987 

Submitted by: David Swanger, Auburn University, 
Auburn University, AL Operating System: VAX/VMS 
V4.3 - V4.5 Source Language: VAX FORTRAN 

Abstract: NO_FRAGMENTS is a program that performs 

pseudo on-line disk compression for VAX systems oper¬ 
ating under the VMS operating system. It will make each 
file in a particular directory tree contiguous if there is 
sufficient contiguous space available on the disk. If the 
chosen directory tree is the main 000000 directory, then 
all of the files on the disk will be restructured. 

SMART is a semi-intelligent program that displays all of 
the interactive processes on a VAX next to the Username 
for each process. SMART reads all of the users on the 
system into an array using a series of LIB & GETJPI 
calls, the array is sorted alphabetically by username and 
printed to the terminal. 

XMODEM_AU is a revised version of Jim Belonis’ 
XMODEM 5.60. The user interface to the program has 
been rewritten. XMODEM is a VAX to VAX file trans¬ 
fer program. 

Notes: XMODEM_AU is a revision of the program 

XMODEM by Jim Belonis. 

Media (Service Charge Code): 600’ Magnetic Tape(MA) 
Format VAX/ANSI 


NEW LIBRARY PROGRAMS AVAILABLE 
FOR THE 

PROFESSIONAL-300 SERIES OF COMPUTERS 

DECUS NO: PRO-169 Title: PRO 2780/3870 Comm¬ 
unications Applications Version: 1.2, May 1987 

Submitted by: Digital Equipment Corporation Operating 
System: P/OS Hardware Required: RCD5X Hard Disk 
Keywords: Utilities - P/OS 

Abstract PRO-2780/3780 is an application for the Pro¬ 
fessional 300 series of personal computers that provides 
communications to systems with capabilities similar to 
IBM 2780 and 3780 remote batch terminals. The product 
runs under the P/OS Hard Disk Operating System. 

PRO-2780/3780 operates using a single, point-to-point 
communications line. This line can be half- or full- duplex, 
and transmission speeds of up to9600 bits per second can 
be achieved on an otherwise idle system. 

The user interacts with the product by means of a hierarchy 
of menus and forms. The product also supplies the user 
with help information that provides a brief description of 
the product and its menus. 

The communications discipline implemented by PRO- 
2780/3780 is a subset of IBM’s Binary Synchronous Com¬ 
munications (BSC) protocol that uses EBCDIC trans¬ 
mission code. Horizontal format control records can be 
received and processed. A subset of vertical format con¬ 
trol escape sequences is supported, specifically single, 
double and triple space, form feed and space suppress. 
Any block addressable storage device supported by P/ 
OS can be used as a source of transmission files. Both 
fixed length (80 character card image) and variable length 
files can be transmitted as EBCDIC (automatically trans¬ 
lated from ASCII) or binary data (no translation). BSC 
control characters are automatical ly added to the data 
before transmission and stripped on reception. Any block 
addressable storage device supported by P/OS can be 
used to receive files. Optionally, received print files can 
be sent to a printer, if one is attached to the Profes¬ 
sional System. 

The following 2780/3780 remote batch terminal features 
are supported: 

. 2780 multiple record transmission option 
. Transparent mode 
. 3780 space compression 
. Variable vertical and horizontal forms control 

Notes: Sources not available. 

Documentation available in hardcopy only. Sources not 
included. 

Media (Service Charge Code): User's Manual (EC), 
One RX50 Diskette (JA) Format FILES-11 


NEW LIBRARY PROGRAMS AVAILABLE 
FOR THE 

PDP-11 COMPUTER FAMILY 

DECUS NO: 11-870 Title: ECR: Enhanced Console 
Routine Version: VI, April 1987 

Submitted by: Frank R. Borger, Michael Reese Hospital, 
Chicago, IL Operating System: IAS V3.1 Source Lan¬ 
guage: MACRO-11 Keywords: Utilities - IAS 

Abstract ECR is an intelligent monitor console routine. 
It is an enhancement to the AUX program as originally 
written by Robin Miller for operation on RSX-11. It 
provides the following enhancements. 

. The last twenty command lines can be recalled and 
edited. 

. Often used commands are defined by numeric keypad 
keys. 

. Up to 48 command line mungers can be defined. Typical 
uses for these would be to define a command that 
expands: 

KEF NAME to KED NAME.FOR 

FOR NAME to F77 NAME,NAME/-SP/CR=NAME 

LINK NAME to TKB @NAME.CMD 

. A default file name option lets ECR remember the last 
name used and use it again if no name is given in the 
command. This would further reduce the commands 
required to edit, compile and link a fortran program to 
the following: 

KEF NAME 

FOR 

LINK 

As an added goodie, we have included the program QUOTE. 
This is a cookie/dammit program that provides notable 
quotations. 

Notes: Operating system IAS V3.1 or higher is required. 

Media (Service Charge Code): 600' Magnetic Tape (MA) 
Format BRU 

DECUS NO: 11-871 Title: IAS KERMIT Version: April 
1987 

Submitted by: Frank R. Borger, Michael Reese Hospital, 
Chicago, IL Operating System: IAS V3.1, V3.2 Source 
Language: MACRO-11 Keywords: KERMIT 

Abstract IAS kermit is Brian Nelson’s RSX-11 KERMIT. 
There are three notable changes made to bring this 
version up under IAS. 

. Bruce C. Wright made the necessary changes to use 
version 1.8 RMSll file I/O. As such, it can not do xxx*.* 
type wildcards but it can do *.*. This will be the case 
until IAS supports version 2 of RMS. 
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. Due to the lack of a get size of readahead qio request 
under IAS, the E P A connect code did one qio per 
character reads. This produced an intolerable burden 
on the system, and limited operation to 300 baud. 
Changes to the connect code done at Michael Reese 
used reads with subsequent mark times followed by a 
kill io, (which returned the partial read.) This allowed 
operation nicely at 1200 baud, (but has not been tested 
above that speed.) 

. The current IAS version is a couple of tapes behind 
Brian’s RSX-11 version. We will make every attempt to 
prepare a version that is only 1 tape behind Brian’s 
work for subsequent DECUS tapes. 

Notes: Operating system IAS V3.1 or higher is required. 

Restrictions: TTY Handler may have to be rebuilt 

Media (Service Charge Code): 600’ Magnetic Tape (MA) 

Format: BRU 


DECUS NO: 11-873 Title: FORTRAN Aids and Tools 
Version: VI, April 1987 

Submitted by: Richard Neitzel Operating System: RSX- 
11M V4.2 Source Language: FORTRAN 77, MACRO-11 
Keywords: FORTRAN, File Management, MACRO, 
Tools - Applications Development, Utilities -RSX-11 

Abstract: There are five major categories of items in¬ 
cluded in this package. 

. Routines to access and manipulate the file structure. 


. Some SST handlers. 

. A software fix for a DL device hardware bug. 
. An undeletion utility. 

. A miscellaneous grab bag. 


Some of the programs in the grab bag are as follows: 


WIND.FTN 


SEARCH. FTN 


COMPS. FTN 


MACLIB.ULB 


This program takes input values 
for temperature and wind speed 
and returns the wind-chill temper¬ 
ature. 

The user enters in a wildcard file 
specification, with optional switch¬ 
es that prompt him for a string to 
locate and the number of lines from 
the file to print on the terminal, 
and the program then displays the 
matching files on the terminal (up 
to 99 lines). 

This program is very useful for 
verifying that the executable ver¬ 
sion of a file is identical to the 
master for software quality assur¬ 
ance purposes. 

This is a collection of assorted 
MACRO routines that all are call¬ 
able from FORTRAN. They per¬ 


form various functions that are 
either impossible from FORTRAN, 
such as performing bit reversals or 
push/popping items onto the stack, 
or are easier and faster in MACRO, 
such as converting lower case to 
upper case or changing an odd into 
an even integer. 

Media (Service Charge Code): One RX02 Diskette (LA) 
Format: FILES-11, 600’ Magnetic Tape (MA) Format 
FILES-11 


DECUS NO: 11-874 Title: DECUS“C” Compiler Changes 
Version: 1.0 April 1987 

Author James Conroy, Unisys Corp, St Paul, MN55164 

Operating System: RSX-11M-PLUS V2.1 Source Lan¬ 
guage: C, MACRO-11 Software Required: DECUS NO’s 
ll-SP-18, ll-SP-90, and ll-SP-92. 

Abstract The new “C” compiler, assembler and runtime 
libraries support I and D space. It was built from the 
DECUS Fall’85 RSX SIG tape (ll-SP-90). Added to it 
were the Australian submissions for split I and D space 
from the Spring‘86 (ll-SP-92). The Australian changes 
can be found in UICs [272,34], [272,35], and [272,37] on 
that tape. Only the changes for I and D space were used. 
The double-precision arithmetic changes were not in¬ 
cluded. The merging of these two tapes has resulted in 
the use of these UICs: 

. [5,4] compiler and assembler modules. 

. [5,15] and C.OLB library routines. 

[5,16] 

. [5,24] CX.OLB library routines. 

The resultant compiling system did not work well and we 
were forced to modify several programs. Specific changes 
to each program are listed in the edit history at the 
beginning of the program. 

Notes: Modifications to use split I & D space. 
Documentation may or may not be on magnetic media. 

Media (Service Charge Code): 600’ Magnetic Tape (MA) 
Format BRU 

DECUS NO: 11-875 Title: RSTS/E 2780 Version: 3.0, 
May 1987 

Submitted by: Digital Equipment Corporation Operating 
System: RSTS/E V6B or later Memory Required: 16K 
Bytes Hardware Required: DUP-11, KG11 for UNIBUS, 
DUV-11 for QBUSS Keywords: Emulators 

Abstract: The RSTS/E-2780 software emulates the com¬ 
munications protocol of an IBM 2780 device, while run¬ 
ning as a user job on a suitably configured RSTS/E 
system. 


The RSTS/E-2780 transmits files stored on any medium 
supported by the RSTS/E Operating System. It stores 
files on any output medium supported by RSTS/E except 
DECtape. Magnetic tape operation can cause timeout 
errors, unless the tape is positioned at the start of the file 
when transmission or reception is about to begin. Files 
can be printed directly on any line printer supported by 
the host operating system. 

RSTS/E supports a spooling feature that allows users 
running with the RSTS/E-2780 to queue one or more files 
for subsequent transmission. 

The processing requirements of the 2780 protocol can 
perceptibly degrade RSTS/E response time during trans¬ 
mission or reception. 

Notes: Will run on PDP 11-23 or Micro PDP-11 by an¬ 
swering system generated question 2780 with a YES/Q. 
Program also works on Version 9.0 of RSTS/E. 

Assoc. Documentation: The RSTS/E 2780 RMT CMP 
System Installation Notes (AA-1151A-TC) and RSTS/E 
2780 RCS User Guide (AA-2675B-TC) are available 
through Digital Equipment Corporation not through 
DECUS. They may be obtained by contacting your local 
Digital Sales Representative. Documentation not avail¬ 
able. Sources not included. 

Media (Service Charge Code): 600’ Magnetic Tape (MA) 
Format DOS-11 

DECUS NO: 11-876 Title: RSTS/E 3271 Protocol Emu¬ 
lator Version: 2.1, May 1987 

Submitted by: Digital Equipment Corporation Operating 
System: RSTS/E Version 8.0 Memory Required: 4K 
Bytes Hardware Required: DUP11-DA, KMC11-A Key¬ 
words: Emulators 

Abstract The RSTS/E 3271 Protocol Emulator permits 
application programs written in BASIC-PLUS, BASIC- 
PLUS 2, COBOL, or DIBOL running under the RSTS/E 
Operating System to communicate interactively with 
user jobs running on an IBM 370 or 303x host system. 
The IBM application program can run with IMS/VS, 
CICS/VS, or TSO. The package makes it possible to 
implement applications performing remote, on-line ac¬ 
cess to IBM Data Bases for data entry, retrieval, and 
update, or file transfer. 

The RSTS/E 3271 Protocol Emulator is a communications 
product only. It does not perform IBM 3277 video display 
emulation nor does it respond to the SENSE, COPY, and 
READ BUFFER commands. 

The communications discipline used by the RSTS/E 3271 
Protocol Emulator is the 3271 subset of IBM’s Binary 
Synchronous Communications (BSC) protocol that uses 
EBCDIC code. Specifically, this subset of BSC supports 
operation of full- and half-duplex leased lines, in either 
poinLto-point or multipoint configurations, at trans¬ 
mission speeds up to 9600 bits per second. The RSTS/E 
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3271 Protocol Emulator does not support switched facil¬ 
ities, contention line control, or transparent BSC capability. 
It can share a multipoint line with control units functioning 
in nontransparent mode only. 

Assoc. Documentation: The RSTS/E 3271 PE Users 
Guide (AA-D365B-TC) and RSTS/E 3271 TE Release 
Notes (H474C-TC) are available through Digital Equip¬ 
ment Corporation not through DECUS. They may be 
obtained by contacting your local Digital Sales Repre¬ 
sentative 

Restrictions: Will not run on PDP-11/23 or Micro PDP- 
11. Requires RSTS/E Version 8 or later. 

Documentation not available Sources not included. 

Media (Service Charge Code): 600’ Magnetic Tape(MA) 
Format: DOS-11 

DECUS NO: 11-877 Title: RSTS/E HPE 2780/3780 
Version: Vl.l MAY 1987 

Submitted by: Digital Equipment Corporation Operating 
System: RSTS/E Version 8.0 or later Memory Required: 
4K Bytes Hardware Required: UNIBUS based RSTS/E 
configuration with RMS support with DUP11-DA and 
KMC11-A Keywords: Emulators Abstract: The RSTS/E 
High Performance 2780/3780 Emulator runs as a user 
job on a suitably configured RSTS/E Operating System 
while emula ting the communications protocol of an IBM 
2780/3780 device. The RSTS/E High Performance 2780/ 
3780 Emulator uses a KMC-11 Microproces sorto handle 
modem and line control, as well as BSC protocol. By 
using a microprocessor to perform these functions, the 
CPU load required to do protocol emulation is reduced. 

The RSTS/E High Performance 2780/3780 Emulator 
appears as an IBM 2780 or 3780 data transmission ter¬ 
minal, in EBCDIC mode, on a poinLto -point switched or 
nonswitched synchronous data link operating with stan¬ 
dard 2780/3780 protocol. Received data blocks can be up 
to the maximum buffer size, which is 400 characters for 
2780 and 512 characters for 3780. 

The RSTS/E High Performance 2780/3780 Emulator can 
transmit and receive data and/or job control files with an 
IBM System/370 (including 303x processor systems) run¬ 
ning Power/VS, HASP, ASP, JES1, JES2, OR JES3. The 
RSTS/E High Performance 2780/3780 Emulator operates 
at transmission speeds up to 9600 bits per second. 
Switched, leased, or private circuits using Bell System 
201, 208, 209, or 212 modems or equivalents are sup¬ 
ported. 

Assoc. Documentation: The RSTS/E 2780/3780 Users 
Manual (AA-J177A-TC) and RSTS/E HPE Version 1.1 
Release Notes (AA-J458B-TC) are available through 
Digital Equipment Corporation not through DECUS. 
They may be obtained by contacting your local Digital 
Sales Representative. 

Restrictions: Will not run on PDP-11/23 or Micro PDP- 
11. Requires RSTS/E Version 8.0 or later. 
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Documentation not available. Sources not included. 
Media (Service Charge Code): 600’ Magnetic Tape(MA) 
Format: DOS-11 

DECUS NO: 11-878 Title: RT-11 2780/3780 Protocol 
Emulator Version: 4.1, May 1987 

Submitted by: Digital Equipment Corporation Operating 
System: RT-11 Memory Required: 32K Bytes Software 
Required: RT-11 with FB or XM Monitor. Hardware 
Required: One of the following - DU11 or DUP11 for 
PDP-11, DUV11 or DPV11 for LSI, SCIfor PDT-11/130 
or PDT-11/150 Keywords: Data Communications, Emu¬ 
lators 

Abstract: The RT-11 2780/3780 Protocol Emulator (PE) 
provides communications capabilities similar to IBM 
2780 and 3780 remote batch terminals. 

The emulator runs under the RT-11 Foreground/Back¬ 
ground (FB) or Extended Memory (XM) monitor as either 
a foreground or background job. The emulator accepts 
commands interactively or from indirect command files. 
Commands are provided for operation in unattended 
environ ments. The emulator supports operation of a 
single full- or half-duplex synchronous poinLto-point 
line at transmission speeds up to 9600 bits per second on 
an otherwise idle system (maximum line speed on PDT- 
11 is 4800 bits per second). Support for automatic answer 
to incoming calls is also available for use with those mod¬ 
ems that provide this capability. 

The communications discipline implemented by the RT- 
11 2780/3780 PE is a subset of IBM’s Binary Synchronous 
Communications (BSC) protocol that uses the EBCDIC 
transmission code. Horizontal format control records 
can be received and processed. A subset of vertical format 
control escape sequences is supported, specifically single, 
double, and triple space, form feed, and space suppress. 
Any block addres sable storage device supported by RT- 
11 can be used as a source of transmission files. Both 
fixed length (80 character card image) and variable length 
transmitted as either EBCDIC (automatically translated 
from ASCII) or binary data (no translation). BSC control 
characters are automatically added to the data before 
transmission and stripped upon reception. Any block 
addressable storage device or line printer supported by 
RT-11 can be used to receive files. 

The following 2780/3780 remote batch terminal features 
are supported: 

. 2780 multiple record transmission option 
. Transparent mode 
. 3780 space compression 
. Variable horizontal forms control 
. Print and punch component selection on receive 

Assoc. Documentation: The RT-11 2780/3780 PE User 
and Installation Guide (AA-J089A-TC) and RT-112780/ 
3780 PE Update Notice (AD-J089A-Tl) may be available 
through Digital Equipment Corporation not through 


DECUS. They may be obtained by contacting your local 
Digital Sales Representative. 

Documentation not available. Sources not included. 

Media (Service Charge Code): Two RX01 Diskettes 
(KB) Format: RT-11, 600’ Magnetic Tape (MA) Format: 
RT-11 


REVISIONS TO LIBRARY PROGRAMS 

DECUS NO: V-SP-53 Title: KERMIT Distribution 
Version: April 1987 

Author: Various 

Submitted by: Frank Da Cruz and Glenn Everhart 
Operating System: IAS, OS/78, OS/8, RSTS/E, RSX- 
11D, RSX-11M, RSX-11M-PLUS, RSX-11S, RT-11, TOPS- 
10, TOPS-20, VMS Source Language: BASIC, BLISS-16, 
BLISS-32, BLISS-36, C, FORTRAN 77, FORTRAN IV, 
FORTRAN, VAX-11, MACRO-10, MACRO-11, MACRO- 
32, PASCAL & MANY OTHERS Keywords: Data Com¬ 
munications, KERMIT 

Abstract: This tape contains a VMS Backup distribution 
made from a KERMIT distribution from Columbia Uni¬ 
versity dated April 22, 1987. It contains all KERMITS 
known to Columbia as of that date plus a large amount 
of documentation. 

To make the distribution fit on one reel of tape, some of 
the less frequently used KERMITS were compressed. 
The decompression routines and instructions on their 
use are included. No KERMITS were dropped, however, 
and all may be extracted. KERMITS needed for Digital 
Equip ment Corporation equipment were generally not 
compressed, and the MS/DOS, CP/M, and C/UN*X/ 
MAC/AMIGA KERMITS, and documentation, were 
generally not compressed. 

Changes and Improvements: Newer versions of essen¬ 
tially all KERMITS. 

Restrictions: See individual *.BWR Files. 

Media (Service Charge Code): 2400’ Magnetic Tape 
(PC) Format: VMS/BACKUP 

DECUS NO: VAX-6 Title: SPICE 3A7 Version: 3A7. 
May 1987 

Submitted by: Digital Equipment Corporation Operating 
System: VAX/VMS V4.3 or later Source Language: C 
Memory Required: 3 MB Software Required: C Compiler 
Keywords: Circuit Simulation 

Abstract: SPICE3 is a general-purpose circuit simulation 
program for nonlinear dc, nonlinear transient, and linear 
ac analyses. Circuits may contain resistors, capacitors, 
inductors, mutual inductors, independent voltage and 
current sources, four types of dependent sources, trans¬ 


mission lines, and the four most common semiconductor 
devices: diodes, BJTS, JFETS, and MOSFETS. 

The SPICE3 version is based directly on SPICE 2G.6. 
While SPICE3 is being developed to include new features, 
it will continue to support those capabilities and models 
which remain in extensive use in the SPICE2 program. 

The ordering information for the manuals are as follows: 

. Order VAX-6 (EB) for Programmer’s Manual 
. Order VAX-6 (EC) for User’s Manual and User’s Guide 

Notes: Full user’s guide, programming manual and user’s 
manual included with this submission. 

Restrictions: U.S. Government export regulations pro¬ 
hibit the distribution of this program outside of the United 
States without the appropriate export licenses. 

Documentation available in hardcopy only. 

Media (Service Charge Code): User’s Manual (EB), 
User’s Manual (EC), 2400’ Magnetic Tape (PA) Format: 
VAX/ANSI, or order VAX-LIB-1 


DECUS NO: VAX-154 Title: Screen Management Sys¬ 
tem Subroutines Version: April 1987 

Submitted by: Kenneth Messer, Allied Electronics 
Operating System: VAX/VMS V4.5 Source Language: 
VAX BASIC Keywords: BASIC, Tools - Applications 
Development 

Abstract: This submission consists of a group of sub¬ 
routines, written in VAX BASIC V2.3, comprising a system 
allowing the relatively simple use of Digital Equipment 
Corporation’s screen management facility. Object code 
compiled under VAX BASIC V3.0 is included. Docu¬ 
mentation is provided, both Runoff and TeX versions. A 
small program, which uses a number of the routines, is 
also included. 

Notes: Operating system VMS V4.5 required as VAX 
BASIC 3.0 is used. 

Changes and Improvements: New routines, bug fixes, 
enhancements 

Media (Service Charge Code): 600’ Magnetic Tape (MA) 
Format: VMS/BACKUP, or order VAX-LIB-4 


DECUS NO: VAX-255 Title: JMU Utilities Version: 
V1.4, May 1987 

Submitted by: Michael O’Neill, James Madison University, 
Harrisonburg, VA Operating System: VAX/VMS V4.4 
Source Language: VAX-11 FORTRAN Software Re¬ 
quired: FMS Keywords: Bulletin Board, Calculators, 
Mail, Utilities - VMS 

Abstract: This submission consists of three utility pro¬ 
grams in use at James Madison University. They consist 
of an FMS based Bulletin Board System, an FMS based 


calculator program that uses the VT keypad, and a check- 
mail utility that allows you to check to see if someone has 
read a mail message that you sent to them. We are 
currently running these programs on a cluster consisting 
of an 8650, 11/785, and 11/780 with common sysuaf, 
netuaf, and VMSmail files. 

The bulletin board system is a graphics based menu 
driven bulletin board that utilizes the cursor keys and 
return key for command selection. It features online help, 
multiple categories, tracking of unread notices, internal 
access to mail and the EDT editor, automatic identification 
of notice owners, and automatic notice expiration. 

The calculator program utilizes the VT keypad to provide 
a four function calculator with memory. It requires FMS 
to operate. 

The mailcheck program allows a user to check to see if 
someone has read a mail message that they had sent. It 
lists notice dates and subjects for all unread notices sent 
from the person running the program to the person being 
inquired about. This version also supports a cluster en¬ 
vironment with common sysuaf and VMSmail files. 

Notes: Operating system VMS Version 4.0 or later re¬ 
quired. 

Changes and Improvements: Several bug fixes and re¬ 
moval of some site specific code. 

Media (Service Charge Code): 600’ Magnetic Tape(MA) 
Format: VMS/BACKUP 

DECUS NO: VAX-183 Title: JUICER ODS-2 Disk and 
File Compression Utilities Version: 2.03, May 1987 

Submitted by: Michael N. LeVine, Naval Weapons Center, 
China Lake, CA Operating System: VAX/VMS V4.5 
Source Language: MACRO-32, VAX FORTRAN Memory 
Required: 3 megabyte Software Required: RUNOFF 
Keywords: Utilities - Disk - VMS 

Abstract: The JUICER package of programs and com¬ 
mand files is provided to the system manager to allow 
him to monitor VAX/VMS ODS-2 disks for disk and file 
fragmentation and to do such compression as might be 
needed. The package is made up of eight parts: 

. JUICER_1 to do stand alone line disk compression. 

. JUICER_2 to do online disk and file defragmentation 

while disk is in use by other users. 

. FRAG to monitor disk fragmentation. 

. FILE to monitor and optionally compress fragmented 
files. 

. DIR to make a map of disk directory structure and its 
file/block usage. 

. DISK to show by user and account the number of disk 
blocks in use, authorized and overdraft. 

. DISKMON to run as a detached process to provide a 
constant monitor of all disk(s) free space. 

. BAD to scan a selected disk for bad blocks and on user 
authorization, try to repair them. 
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JUICER_1 is an inplace disk compression utility for 

VAX/VMS ODS-2 disks suffering from excessive frag¬ 
mentation. This program, within limitations, attempts to 
move portions of files from the high end of the disk to any 
unused areas (fragments) at the low end. 

JUICER_2 defragments the most defragmented files it 

can find that will fit in the largest contiguous free areas 
on disk, and moves other files as far down toward the low 
end of the disk as it can. 

FRAG is run on a disk to see how badly the target disk 
free space is fragmented, giving a histogram of frag¬ 
mented areas by size, and a calculated measure of the 
disk free space fragmentation and, if wanted, a map of 
free fragments by starting LBN vs size. 

FILE scans all the file headers on the target disk and out¬ 
puts two list files, one containing a list of the 100 files 
having the most retrieval pointers in use, and the second 
being a matrix of file size versus number of pointers in 
use. 

DIR scans a target disk and creates an output file 
DIRECTORY.MAP containing a graphical output showing 
the on disk directory structure, with a notation for each 
directory showing the number of files and blocks con¬ 
tained therein. 

DISK.COM sets up data for the program DISK.EXE 
which produces a list by user and account (for each disk 
specified) of disk blocks in use, authorized and per¬ 
mitted overdrafts. 

DISKMON is a detached process which constantly 
monitors all disks on the system and warns when free 
space falls below preset values. 

Changes and Improvements: Additional utilities, up¬ 
dated online version of Juicer added. 

Restrictions: Does not do volume setting. Operating sys¬ 
tem VMS V4.X or later. Will not run under V3.X because 
of change in ODS-2. 

Media (Service Charge Code): 600’ Magnetic Tape (MA) 
Format VMS/BACKUP 


DECUS NO: 11-750 Title: TEM: A Terminal EMulator 
for RSX-11 Version: V87.077, April, 1987 

Submitted by: Thomas R. Wyant III, E. I. du Pont de 
Nemours, Richmond, VA Operating System: Micro/ 
RSX V3.0, RSX-11M-PLUS V3.0, RSX-11S V4.1, VAX-11 
RSX V2.0 Source Language: MACRO-11 Memory Re¬ 
quired: 16KW Hardware Required: Communicating with 
another system or device requires a link to the system 
running TEM. Keywords: Data Communications, Emu¬ 
lators, Utilities - RSX-11 

Abstract TEM provides “dumb” terminal emulation 
over a full duplex TT: line. It allows the user to “become” 
a terminal on a remote system, and to do ASCII file 


transfers between systems. TEM has been used to com¬ 
municate with RSX-11, VMS, RSTS and TOPS-20 sys¬ 
tems, as well as non-Digital Equipment Corporation 
equipment. It requires no software on the remote system 
(and therefore has no error checking). 

In addition to the basic functionality, TEM can auto¬ 
matically issue canned commands to smart modems at 
the beginning and end of a session. The user can also 
select from the following features: 

. Local Echo. 

. Automatic line feed on carriage return. 

. Translation of inbound control characters to ASCII 
abbreviations. 

. Passthru of control/s, control/q, control/o and control/x 
to the remote system. 

. User selectable attention and end-of-file characters. 

. Inbound and outbound character mapping. 

. Specifiable record delay and prompt character for file 
transfer. 

. Parity generation and checking. 

. Support for dialout modems as remote devices. 

TEM requires at least RSX-11M-PLUS V2.0, VAX-11 
RSX V2.0, RSX-11M V4.0 or RSX-11S V4.0. If running 
under RSX-11M or RSX-11S, it requires the full-duplex 
TT: driver, get/set multiple character istics, and unso¬ 
licited input AST’s. Correct access of named directories 
and files numbered in decimal requires the FEAT$ 
directive. The GIN$ directive is used to prevent non- 
privileged users from using TEM to read files that are 
none of their business (e.g. LB:[0,0]RSX11.SYS). An 
attempt has been made to conditionalize TEM for RSX- 
11M V3.2, but it has not been checked. TEM can be 
initiated from and communicate with any reasonable 
serial device, but there may be restrictions if not being 
used on a TT:type device. 

Notes: Requires full-duplex TT: driver, get/set multiple 
characteristics. 

Changes and Improvements: Fixed batch support, added 
username to log file, added remote echo. 

Media (Service Charge Code): Two RX01 Diskette (KB) 
Format: RT-11,600’ Magnetic Tape (MA) Format: DOS- 
11 

DECUS NO: 11-833 Title: Management Tools Version: 
V8.705, May 1987 

Submitted by: M. D. Smith, WAAY-TV (Smith Broad¬ 
casting, Inc.), Huntsville, AL Operating System: RSTS/ 
E V9.3 Source Language: BASIC-PLUS Memory Re¬ 
quired: 16K Bytes Software Required: BASIC-PLUS 
Keywords: Business Applications, Utilities - RSTS/E 

Abstract: Management Tools is a series of ten programs 
written by a manager with twenty-three years experience 
as a manager, including ten years teaching management 
seminars. There are documentation files for each of the 
following: 


. EVALUE.BAS Employee evaluation 
. COMMUN.BAS Communication effectiveness 
. TIMEFI.BAS Time management improvement 
. DECISI.BAS Decision making help 
. DELEGA.BAS Be a better delegator 
. MOTIVA.BAS Motivation of people and self 
. MANAGE.BAS Better overall manager of people 
. MYBOSS.BAS Boss evaluation program 
. PLANS.BASPlanning improvement 
. GETDUN.BAS Getting more done in a day 
. INTERV.QES Interviewing prospective employees 

The more times a manager uses these programs, the 
more benefits he/she will gain. There are options foi 
hardcopy printouts of various portions of the programs 
as they run or they can be stored in files. 

These programs were originally written on my MS/DOS 
PC at home and were further modified to run on a C-64 
and an APPLE computer. The basic code used is highly 
transportable for this reason and will run, with only 
minor modifications, on any computer that runs BASIC. 

Non-management personnel will also find benefits in 
these programs for business and private lives. 

Changes and Improvements: Includes ten programs 
and DOC files, a text file, and a READ.ME overall docu¬ 
mentation file. Media (Service Charge Code): 600’ Mag¬ 
netic Tape (MA) Format DOS-11 DECUS NO: PRO-156 
Title: FORTRANUM Version: Vl.l, March 1987 

Submitted by: Jorg Buchner, D-5064 Rosrath, West 
Germany Operating System: P/OS V2.0 Source Lan¬ 
guage: FORTRAN 77, MACRO-11 Memory Required: 
365KB Keywords: FORTRAN, Tools - Applications 
Development 

Abstract FORTRANUM renumbers statement-numbers 
(labels) in the source code of FORTRAN programs. It is 
designed for programmers who in the process of building 
a program want to alter or reorganize part or all of the 
program’s statement-numbers. The complete DEC-FOR¬ 
TRAN 77 statement - (command-) set can be processed. 
The old program version is saved. 

The user denotes a program section by specifying: 

. the first statement-number which shall be changed 
(and its new value). 

. the last statement-number which shall be changed. 

Within this program section, all statement-numbers are 
changed in ascending order. The increment between two 
consecutive statement -numbers is also variable. 

Although the author has no experience with the program 
RENUM by E. Morton, (DECUS Library No. PRO-112), 
FORTRANUM’s new features seem to be only its oper¬ 
ating system (P/OS) and the FORTRAN 77 capability. 

Changes and Improvements: Bugs removed. 
Restrictions: Mentioned in the documentation. 

Media (Service Charge Code): One RX50 Diskette(JA) 
Format: FILES-11 


DECUS NO: PRO-155 Title: RT Programs for PRO 
Version: April 1987 

Submitted by: C. E. Chew Operating System: RT-11 
V5.02 Source Language: MACRO-11, NBS PASCAL 
Software Required: NBS PASCAL required to recompile 
some programs if customization is needed. Keywords: 
Device Handlers, Spell, Text Formatting, Utilities -RT- 
11 


Abstract: This is a potpourri of programs written for RT- 
11 V5.1 or later (except where noted) on a PRO. The 
following have been provided: 


PL 

Cl 

MENU 

TYPO 

MORE 

OTHER 

WP 


DZCOPY 


XHANDL 


PRTSCR 


A pipeline handler which functions ir 
much the same way as MQ: except tha 
no special .LOOKUP requests are needed 
A console interface which allows one job 
to ‘type’ input to another. 

A suite of rather crude menu control sub¬ 
routines. 

A typographical error checker written in 
NBS PASCAL. 

A file perusal utility written in NBS 
PASCAL. 

A program which determines which drive 
(0 or 1) RT is booted from and assigns 
logical names to it (SYS) and the other 
drive (DK and DSK). 

A program utilizing all the above to allow 
the creation of a cheap but effective text 
formatting system using KEX and RUN¬ 
OFF (you have to provide your own KEX 
and RUNOFF). 

Program to make a sector by sector image 
of a foreign disk by using the DZ con¬ 
troller hardware. Has been used to read 
IBM format 5.25 inch disks. 

An alternative overlay handler which can 
force large root segments and large over¬ 
lay tables into extended memory. Moved 
code to allow for .module code. 

A screen dump utility. It can be custom¬ 
ized for non Digital Equipment Corpor¬ 
ation printers, requires less low memory 
than the SPOOL utility, and can dump in 
text or graphics mode, but requires V5.02. 


Note that some programs may require a little experience 
with RT and MACRO to customize, but should be fairly 
easy to put together. 


Changes and Improvements: Bugfix to XHANDL. 

Media (Service Charge Code): One RX50 Diskette(JA) 
Format: RT-11 
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SUBMITTING ARTICLES TO THE HMS SIG NEWSLETTER 


The purpose of the HMS SIG newsletter is to serve as a forum 
to share information related to DEC hardware with the 
members of the SIG. As such, the existence of the 
newsletter is entirely dependent on your contributions. If 
you have an HHK item, a better or safer way to do something, 
product news, a tutorial article of general interest, etc., 
we are interested in publishing it in the newsletter. It is 
intended that the HMS newsletter be published at least four 
times a year. 

You can submit material to either the editor. Bill Walker, 
or the assistant editor. Carmen Wiseman. We can accept sub¬ 
missions in a wide variety of formats: 

o Items can be sent to the assistant editor on VMS 

format RX50s or IBM PC format 5 1/4" floppies. 

o The editor can handle just about any reasonable 
media, but prefers RT-11 format diskettes. 

o Hard copy, like cash, is always acceptable. If it 
is camera-ready it will save us a lot of typing, 
but we don't insist on it. You can also use the 
"Hardware Submission Form," which you will find in 
the "Questionnaire" section of the combined 
newsletters. 

o Those of you that have access to DCS can send 

things to WALKER or WISEMAN. DCS is usually 

checked on a daily basis. 

o You can reach the editor on CompuServe as 

"Bill Walker 71066,24" or via EasyLink mailbox 
62752448. You can reach the assistant editor via 
EasyLink mailbox 62960090 (be sure to say ATTN: or 
TO: Carmen Wiseman somewhere in the message). 

In any event, if you have anything to submit, send itl If 
it is a mess, but we can read it, we will get it in the 
newsletter somehow. Finally, if you have any question about 
submitting material, call one of us. The telephone numbers 
are listed below. 

Contributions can be sent to: 

William K. Walker Carmen D. Wiseman 

Monsanto Research Corp. OR Digital Review 

P.O. Box 32 A-152 == Prudential Tower, Suite 1390 

Miamisburg, OH 45342 800 Boylston Street 

(513) 865-3557 (work) Boston, MA 02199 

(513) 426-7094/0344 (home) (617) 375-4361 
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How to Submit to the RSTS Newsletter 


The RSTS SIG newsletter solicits contributions of items of 
interest including, but not limited to, articles, DCL magic, 
copies of SPR’s, and war stories. 

You may electronically submit material by calling the SIG 
newsletter system at (201) 435-2546 at either 300 or 1200 baud. 
Press a few RETURN'S until you get the RSTS banner, then sign 
on with account 2,1. No password is required. KERMIT is 
available for uploading material. Then you can use MAIL to 
compose a cover letter for your material and send it to NEWS. 

You may also submit material on RX50' s (in RSTS or RT11 
format), on 800, 1600, 3200, or 6250 BPI 9-track tape (in DOS, 
ANSI, BRU, RSTS BACKUP or VMS BACKUP format), or on PC-DOS 
floppies (5& or 3 % inch format). If you are really desperate, 
I can also accept RSTS or RT11 format RL02 and RK07 disks. You 
may also submit hardcopy documents, but these will take longer 
to get into print. 

If you are sending media you want returned, please insure 

it. 


If you want your submission returned, please include a 
completed airbill billed to you, or include reasonable funds 
for insurance and return. 

The address for sending material via US Mail is: 

Terence M. Kennedy 
St. Peter's College 
Department of Computer Science 
2641 Kennedy Blvd. 

Jersey City, N.J. 07306 
(201) 435-1890 

The address for sending material via UPS, FedEx, etc. is: 

Terence M. Kennedy 
St. Peter's College 
Department of Computer Science 
121 Glenwood Avenue 
Jersey City, N.J. 07306 
(201) 435-1890 
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DECUS 


DECUS U. & CHAPTER 

SUBSCRIPTION SERVICE SIGS NEWSLETTERS ORDER FORM 

(U.S. Members Only) 


As a member of DECUS U.S. Chapter, you are entitled to contribute and subscribe to the DECUS monthly pub¬ 
lication, SIGs Newsletters. You also have the opportunity to subscribe to the Symposia Proceedings which are a 
compilation of the reports from various speakers at the U.S National DECUS Symposia 


• No Purchase Orders will be accepted. 

• The order form below must be used as an invoice 

• All checks must be made payable to DECUS 

• All orders MUST be paid in fulL 

• Minimum of $25.00 for orders placed via a credit card 

• No refunds will be made. 

• The address provided below will be used for all DECUS mailings; Le Membership Subscription Service and 
Symposia 

• SIGs Newsletters Price is for a one-year subscription beginning the month following receipt of payment 


Name_DECUS Member#. 

Company_ 

Address_ 


City_State_Zip 

Telephone #_ [ _!_ 


Subscription Service Offering Unit Price Qty Total 

SIGs Newsletters $35.00 _ _ 

Spring’86 Proceedings (SP6) 15.00 _ _ 

Fall’86 Proceedings(FA6) 15.00 _ _ 

Spring’87 Proceedings (SP7) 15.00 _ _ 

Fall’87 Proceedings(FA7) 15.00 _ _ 


Total Amt $- 

□ MASTERCARD □ VISA □ DINERS CLUB/CARTE BLANCHE® 

Credit Card #____Expiration Date 


I understand that there will be no refunds even if I decide to cancel my subscription. 

Signature_____ 

For Digital Employees Only 

Badge #_Cost Center_ 

Cost Center Mgr. Name_ Cost Center Mgr. Signature_ 

MAIL TO: Subscription Service, DECUS(BR02), 219 Boston Post Road, Marlboro, MA01752-1850, (617)480-3418. 


FOR DECUS OFFICE ONLY 

Check Number _ Bank Number - 

Amounts 
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j [TV DECUS U.S. CHAPTER 
Isa APPLICATION FOR MEMBERSHIP 

• DECUS 

1 

■ □ New Membership □ Update to current membership profile Current DECUS Member.#_ 

■ Please provide a complete mailing address, include zip code in accordance with postal regulations for your locality. 

■ Are you an employee of Digital Equipment Corporation? □ YES □ NO 
S NOTE: Please print clearly or type! 

S Name:_ 

■ (First) (Middle Initial) (Last/Family Name) 

■ Company: _ 

■ Address:_ 


City/Town/State/Zip: 


B Telephone: Home( )_ Work( )_ 

i 

* 

■ How Did You Learn About DECUS? Please Check Applicable Item. 

» 

{ 1 □ ANOTHER DECUS MEMBER 4D DIGITAL SALES 13D LOCAL USERS GROUP 

j 2 □ SYMPOSIA 5 □ HARDWARE PACKAGE 14D SPECIAL INTEREST GROUP 

• 8 □ DECUS CHAPTER OFFICE 6D SOFTWARE PACKAGE 7D SOFTWARE DISPATCH (Digital Newsletter) 

• 10 □ DIGITAL STORE 12 □ ADVERTISING 


{ Do you wish to be included in mailings conducted by Digital (for marketing purposes etc.?) □ Permission 
• □ Refusal 

; Type Of Digital Hardware Used: Please Check Those Applicable To You. 


20 □ 

DECMATE 


52 □ LSI-11 


21 □ 

PROFESSIONAL 5 0 

WPS-8 


82 □ 

DECSYSTEM-10 

3 □ PD P-8 FAMILY 

22 □ 

RAINBOW 

51 □ 

WPS-11 


83 □ 

DECSYSTEM-20 

50 □ PDP-11 

FAMILY 

54 □ 

VAX FAMILY 




Major Operating Systems? Languages Used: Please Check Those Applicable To You. 



i □ 

ADA 

26 □ 

CORAL-66 

47 □ 

FOCAL 

67 □ 

OS/8 

109D 

RT-11 

2 D 

ALGOL 

28 □ 

COS 

48 □ 

FORTRAN 

68 □ 

PASCAL 

97 □ 

TECO 

5 □ 

APL 

34 □ 

DATATRIEVE 

51 □ 

GAMMA 

72 □ 

PL-11 

70 □ 

TOP& 10 

7 □ 

BASIC 

35 □ 

DBMS 

110D 

IAS 

92 □ 

RPG 

71 □ 

TOPS-20 

17 n 

BLISS 

38 □ 

DECNET 

53 □ 

IQL 

81 □ 

RSTS/E 

111 □ 

ULTRIX/UNIX 

19 □ 

C 

43 □ 

DIBOL 

58 □ 

MACRO 

83 □ 

RSX 

104 □ 

VMS 

22 □ 

COBOL 

45 □ 

DOS'! 1 

65 □ 

MUMPS 

91 □ 

RMS 

107 □ 

WPS-8 
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Type Of Business (Environment)/Computer Applications 

Please Check That Which Best Describes Your Business/Application. 


21 □ ACCOUNTANCY 
7 □ BANK 

64 □ BUSINESS/COMMERCIAL 

74 □ BUSINESS/INFORMATION SYSTEMS 

57 □ CHEMISTRY 

54 □ CLINICAL LABORATORY 

63 □ COMPUTATION 

11 □ CONSUMER ELECTRONICS 

18 □ CONSULTANT 

72 □ DATA ACQUISITION 

52 □ DATA COMMUNICATIONS 

13 □ DATA PROCESSING SERVICES 

71 □ DATA REDUCTION 

17 □ DIGITAL EMPLOYEE-ENGINEERING 

15 □ DIGITAL EMPLOYEE-MARKETING 

16 □ DIGITAL EMPLOYEESERVICE GROUP 
60 □ EDUCATIONAL ADMINISTRATION 


1 □ EDUCATION/PRIMARY 

2 □ EDUCATION/SECONDARY 

61 □ EDUCATION-TECHNOLOGY 

3 □ EDUCATION/UNIVERSITY 
67 □ ENGINEERING 

65 □ FINANCE/ACCOUNTING 
77 □ GOVERNMENT 
75 □ GRAPHICS 

4 □ HOSPITAL 

62 □ INDUSTRIAL 

55 □ LABORATORY/SCIENTIFIC 
14 □ LIBRARY 

58 □ LIFE SCIENCES 
70 □ MANUFACTURING 
79 □ MARKETING 

59 □ MEDICAL RESEARCH 

6 □ MILITARY INSTALLATION 


NUMERICAL CONTROL 

OEM-COMMERCIAL 

OEM-TECHNICAL 

PHYSICAL SCIENCES 

RESEARCH/DEVELOPMENT 

RETAIL 

SOFTWARE DEVELOPMENT 

TELECOMMUNICATIONS 

TELEPHONE/UTILITIES 

TIMESHARING 

TRAINING/INSTRUCTION 

TYPESETTING/PUBLICATION 


Special Interest Groups(SIGs) Enrollment 

I Wish To Participate In The Following DECUS U. S. Chapter Special Interest Groups. 


3 □ ARTIFICIAL INTELLIGENCE 

7 □ BUSINESS APPLICATIONS 
2 □ COMMERCIAL LANGUAGES 
6 □ DATA MGMT. SYSTEMS 

31 □ DAARC(LABS) 

5 □ DATATRIEVE/4GL 

8 □ EDUSIG 

10 □ GRAPHICS APPLICATIONS 


11 □ HARDWARE AND MICRO 
35 □ IAS 

27 □ LARGE SYSTEMS 
16D L&T 

14 □ MUMPS 

15 □ NETWORKS 

34 □ OFFICE AUTOMATION 


36 □ PERSONAL COMPUTER 

18 □ RSTS/E 
17 □ RSX 

19 □ RT-11 

32 □ SITE MGMT. & TRNG 
21 □ UNISIG 
26 □ VAX 


jj Job Title/Position - Please Check: 

» 

jj 1 □ CORPORATE STAFF 
: 2 □ DIVISION OR DEPARTMENT STAFF 
S 3 □ SYSTEMS ANALYSIS 
| 4 □ APPLICATIONS PROGRAMMING 
f 5 □ SYSTEMS ANALYSIS/PROGRAMMING 

I 6D OPERATING SYSTEM PROGRAMMING 
7 □ DATABASE ADMINISTRATION 
8 □ DATA COMMUNICATIONS/TELECOMMUNICATIONS 
| 9 □ COMPUTER OPERATIONS 

S 10 □ PRODUCTION CONTROL 


101 □ 
102D 

103 □ 

104 □ 

105 □ 

106D 

107D 

108D 

109 □ 

HOD 


CORPORATE DIRECTOR OF DP/MIS 

ADMINISTRATIVE ASSISTANT 

TECHNICAL ASSISTANT 

SERVICES COORDINATOR 

MANAGER 

ANALYST 

PROGRAMMER 

DATABASE MANAGER 

DATABASE ADMINISTRATOR 

MANAGER OF DP OPERATIONS 


Citizen of The United States of America? □ YES □ NO Country. 


Signature:_ 

Forward To: 


DECUS U. a Chapter 

Digital Equipment Computer Users Society 

Membership Processing Group 

219 Boston Post Road, BP02 

Marlboro^ MA 01752-1850 

Phone: (617)480-3418 

DTN: 8-296-3418 
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STEERING COMMITTEE LISTS 



ARTIFICIAL INTELLIGENCE SIG 

CHAIR 

Cheryl Jalbert 
JCC 

128 West Broadway 
Granville, OH 43023 
(614) 587-0157 

VICE-CHAIR 

OPS5 WORKING GROUP CHAIR 

Don Rosenthal 

Space Telescope Science Inst. 

Homewood Campus 
Baltimore, MD 21218 
(301) 338-4844 

NEWSLETTER TASK FORCE CHAIR 
ADMINISTRATIVE ASSISTANCE 

Becky Wise 
Amdalh CSD 

2200 North Greenville Ave. 

Richardson, TX 75081 
(214) 699-9500 x 272 
NEWSLETTER EDITOR 
Terry Shannon 
Digital Review 
Prudential Tower 
800 Boylston St. Suite 1390 
Boston, MA 02199 
(617) 375-4321 

SYMPOSIA COORDINATOR 

Pam Vavra 

Hughes Aircraft EDSG 
P.O. Box 902 E52/D220 
El Segundo, CA 90245-0902 
(213) 616-7071 

MEMBERSHIP COORDINATOR 
SUITE COORDINATOR 

Chris Goddard 
Simpact Associates 
9210 Skypark Court 
San Diego, CA 92123 
(619) 565-1865 

SESSION NOTE EDITOR 

George Humfeld 
Naval Sea Systems Command 
PMS 350 ED Dept of the Navy 
Washington, DC 20362-5101 
(202) 692-0137 

ASS’T SESSION NOTES EDITOR 

David Frydenlund 
STORE REPRESENTATIVE 
Sally Townsend 
Inst. Defense Analysis 
1801 N. Beauregard St. 

Alexandria, VA 22311 
(703) 845-2122 
PSS REPRESENTATIVE 
Tom Viana 

PUBLIC DOMAIN SOFTWARE TF CHAIR 

Jim Sims 

SITE COORDINATOR, NASHVILLE 
Dennis Clark 

REPORTER TO THE UPDATE.DAILY 
Bill Lennon 

DEC COUNTERPART 

Art Beane 
Hudson, MA 

MEMBERS-AT-LARGE 

David Slater 
George Winkler 
Jeff Fox 

John Williamson 

Wayne Graves 
Matt Mathews 




BUSINESS APPLICATIONS SIG 

CHAIRMAN 

George Dyer 
Gallaudet University 
800 Florida Ave, NE-EMG Bldg 
Washington, DC 20002 
(202) 651-5300 

COMMUNICATIONS REPRESENTATIVE 
SESSION NOTE EDITOR 
STORE REPRESENTATIVE 
NEWSLETTER EDITOR 

Steve Lacativa 
Price Waterhouse 
153 East 53rd Street 
New York, NY 10022 
(212) 371-2000 x 3107 
SYMPOSIA COORDINATOR 
Steve Simek 
IRT Corporation 
3030 Callan Road 
San Diego, CA 92121 
(619) 450-4343 

LRP AND MARKETING COORDINATOR 

Arnold I. Epstein 
D-M Computer Consultants 
Rolling Meadows, IL 60008 
(312) 394-8889 

LIBRARY REPRESENTATIVE 

David Hittner 
Projects Unlimited 
3680 Wyse Road 
Dayton, OH 45414 
(513) 890-1800 
CL SIG LIAISON 

Becky Burkes-Ham 

DMS SIG LIAISON Joe Sciuto MEMBERS-AT-LARGE 

Robert D. Lazenby 
Dixie Beer Dist, Inc. 

Louisville, KY 
Robert Kayne 
Gallaudet College 
Washington, DC 
Ray Evanson 
Paragon Data Systems 
Winona, MN 

DEC COUNTERPARTS 

Sue Yarger 
Merrimack, NH 
Ray Arsenault 
Merrimack, NH 


COMMERCIAL LANGUAGES SIG 

CHAIR 

Dena Shelton 
Cullinet Software Inc. 

2860 Zanker Rd., Suite 206 
San Jose, CA 95134 
(408) 434-6636 

SYMPOSIA COORDINATOR 

Ray Strackbein 
Palm Desert, CA 
LIBRARY COORDINATOR 
Philip Hunt 
System Industries 
Milpitas, CA 

COMMUNICATIONS REPRESENTATIVE 
NEWSLETTER EDITOR 

Ted Bear 
Ramtek 

2211 Lawson Lane 
Santa Clara, CA 95950 
(408) 988-2211 

SESSION NOTE EDITOR 

Bob Van Keuren 
Userware International, Inc. 

2235 Meyers Avenue 
Escondido, CA 92025 
(619) 745-6006 

ASS’T NEWSLETTER EDITORS 

Beverly Welbome 
Diocese of Gary 
LaPorte, IN 
Kevin Cullen 
VITA-Mix Corp. 

Holmstead Falls, OH 
Daniel Cook 

Userware International, Inc. 

Escondido, CA 

BASIC Working Group Members 
Mark Hartman 
Jadtec Computer Group 
Orange, CA 
Rocky Hayden 
Userware International, Inc 
Escondido, CA 
Bill Tabor 
Computer Products 
Pompano Beach, FL 
Ted Bear 
Ramtek 

2211 Lawson Lane 
Santa Clara, CA 95950 
(408) 988-2211 

COBOL WORKING GROUP MEMBERS 

Keith Batzel 
Crowe, Chizek & Co. 

South Bend, IN 
Mary Anne Feerick 
RDBS Inc. 

Kernersville, NC 
Bill Leroy 

The Software House, Inc. 

Atlanta, GA 

Herbert J. Matthews IV 

ManTech international Cor. 

Alexandria, VA 
Jim Welbome 
Crowe, Chizek & Co. 

South Bend, IN 
Jim Wilson 
Pfizer Inc. QC Div. 

Terre Haute, IN 
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DATATRIEVE/4GL SIG 

CHAIRMAN 

Joe H. Gallagher 
Research Medical Center 
2316 East Meyer Blvd 
Kansas City, MO 64132 
(816) 276-4235 
PAST SIG CHAIRMAN 
Larry J asmann 
U.S. Coast Guard 
10067 Marshall Pond Rd. 

Burke, VA 22015 

(202) 267-2626 

SYMPOSIA COORDINATOR 

T.C. Wool 

E.I. duPont DeNemours & Co. 
Engineering Dept. 

P.O. BOX 6090. 

Newark, DE 19714-6090 
ASST SYMPOSIA REPRESENTATIVE 
Lisa M. Pratt 
Vitro Corporation 
Nuwes Code 3144 
Keyport, WA 98345 
(206) 396-2501 

COMMUNICATIONS REPRESENTATIVE 

NEWSLETTER EDITOR 

LRRP 

Donald E. Stem, Jr. 

Warner Lambert Company 
10 Webster Road 
Milford, CT 06460 

(203) 783-0238 
ASSOCIATE EDITOR 

Steve Cordiviola 
Kentucky Geological Survey 
311 Breckinridge Hall 
Lexington, KY 40506 

(606) 257-5863 
Pasquale (Pat) F. Scopelliti 
Corning Glass Works 
Mail Stop MP-RO-01-1 
Coming, New York 14831 

(607) 974-4496 
Lorey'B. Kimmel 
Thomson-CGR Medical Corp. 

10150 Old Columbia Road 
Columbia, Maryland 21046 
(301) 290-8757 

ASST. VOLUNTEER COORDINATOR 

Susan Krentz 
NKF Engineering 
12200 Sunrise Valey Dr. 

Reston, VA 22091 
(703) 620-0900 

PRE-SYMPOSIA SEMINARS 

Dana Schwartz 
15719 Millbrook Lane 
Laurel, MD 20707 
(301) 859-6277 

SESSION NOTES EDITOR 

Wanda Anderson 
SRI International MS: pN341 
333 Ravenswood Avenue 
Menlo Park, CA 94025 
(415) 859-2577 
CAMPGROUND 

Bert Roseberry 
Commandant (G-APA-1) 

2100 2nd Street, S.W. 

Washington, DC 20593-0001 
(202) 267-2629 


WW EDITOR 

PIR COORDINATOR 

LRRP 

Philip A. Naecker 
Consulting Engineer 
3011 N. Mount Curve Ave. 

Altadena, CA 91001 
(818) 791-0945 
DEC COUNTERPARTS 
DATATRIEVE 

Mary Ann Fitzhugh 
110 Spit Brook Road 
ZK2-2/M28 
Nashua, NH 03060 
(603) 881-2329 

ARTIST & LIBRARY REP. 

Bart Z. Lederman 

I.T.T. World Communications 

67 Broad Street (28th Floor) 

New Yor, NY 10004 
(212) 607-2657 

POWERHOUSE W/G CHAIR 
Randall R. Barth 
Searle Fred Vietri 
TSO Financial Corp. 

Five TSO Financial Center 
Three Hundred Welsh Road 
Horsham, PA 19044-2009 
(215) 784-0520 

MEMBER LRPP COMMITTEE 

Michael G. Graham 
Sanders Associates, Inc. 

NAM 3-1, C.S. 2044 
Nashua, NH 03061-2004 
(603) 885-5206 

DMS& CL SIG LIAISON 
William Tabor 
Computer Products 
Pompano Beach, FL 

SMARTSTAR WORKING GROUP CHAIR 

Leslie Byars 
Coming Electronics 
3900 Electronics Drive 
Raleigh, NC 27604 
(919) 878-6301 

ACCENT R USER GROUP LIAISON 
Winston Tellis 
Fairfield University 
North Benson Road 
Fairfield, CT 06430 
(203) 255-5411 



DAARC SIG 

CHAIRMAN 

James Deck 

Inland Steel Research Lab. 
3001 East Columbus Drive 
East Chicago, IL 46312 
(219) 392-5613 

SYMPOSIA COORDINATOR 

Mack Overton 
FDA 

Chicago, IL 


COMMUNICATIONS REPRESENTATIVE 
NEWSLETTER EDITOR 

Ellen Reilly 
William H. Rorer 
500 Virginia Drive 
Ft Washington, PA 19034 
(215) 628-6547 
DEC COUNTERPART 
Bill Forbes 
Marlboro, MA 

HARDWARE & INTERFACING 

Peter Clout 

Los Alamos National Lab 
Los Alamos, NM 

MATH STATISTICS & ANALYSIS 

Herbert J. Gould 

C.C.F.A. Univ. of Ill. Medical Ctr. 

Chicago, IL 

PROCESS CONTROL-INDUSTRIAL AUTOMATION 

Bill Tippie 

Kinetic Systems Corp. 

Lockport, IL 

RS-1 

George Winkler 
CPC International 
Argo, IL 



DATA MANAGEMENT SYSTEMS SIG 

CHAIRMAN 

Joseph F. Sciuto 
Army Research Institute 
5001 Eisenhower Ave 
Alexandria, VA 22333 
(202) 274-8221 
COMPTROLLER 

Alan Schultz 

Land Bank National DP Center 
7300 Woolworth Ave 
Omaha, NE 68124 
(402) 397-5040 

SYMPOSIA COORDINATOR 

Keith Hare 
JCC 

P.O. Box 463 
Granville, OH 43023 
(614) 587-0157 

SYMPOSIA COORDINATOR 

Barbara Mann 
TRW 

Redondo Beach, CA 
(213) 532-2211 

COMMUNICATIONS REPRESENTATIVE 
NEWSLETTER EDITOR 

Mark S. Crego 
Mantech Int’l Corp. 

2121 Eisenhower Ave. 

Alexandria, VA 22314 
(703) 838-5677 

SESSION NOTE EDITOR 
Mark Morgan 
Farm Credit Banks 
P.O. Box 141 
Springfield, MA 01102 
(413) 732-9721 

MEMBERSHIP COORDINATOR 

Vacant 
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PRODUCT DIRECTION COMMITTEE 
PAST SIG CHAIRMAN 

Steve Pacheco 
Ship Analytics 
North Stonington, CT 06359 
(203) 535-3092 

WORKING GROUP COORDINATOR/ 
DATABASE WORKING GROUP 

Jim Perkins 
PSC, Inc. 

20 Kimball Ave., Suite 305 
Shelburne. VT 05401 
(802) 863-8825 

FORMS WORKING GROUP 
ANSI STANDARDS COORDINATOR 

Paul W. Plum, Jr 
Lukens Steel Company 
Coatesville, PA 
(215) 383-2024 

NON-DIGITAL WORKING GROUP 

Doug Dickey 

GTE Government Systems 
1700 Research Blvd 
Rockville, MD 20850 
(301) 294-8400 

RMS WORKING GROUP COORDINATOR 

Allen Jay Bennett 
Lear Siegler Rapistan 
555 Plymouth N.E. 

Grand Rapids, MI 49505 
(616) 451-6429 

PRE-SYMPOSIUM SEMINAR COORDINATOR 

Rocky Hayden 
Userware International 
Escondido, CA 
(619) 745-6006 

AI SIG LIAISON 

David Slater 

Institute for Defense Analysis 
Alexandria, VA 
(703) 845-2200 

DATATRIEVE SIG LIAISON 

William I. Tabor 
W.I. Tabor, Inc. 

Coral Springs, FL 
(305) 755-7895 
DEC COUNTERPART 
Wendy Herman 
Nashua, NH 



EDUSIG 

CHAIRMAN 

Robert A.Shive, Jr. 

Millsaps College 
Jackson, MS 39210 
(601) 354-5201 

SYMPOSIA COORDINATOR 
Mary Jac Reed 
Off Comp Based Instruction 
University of Delaware 
305 Willard Hall 
Newark, DE 19716 
(302) 451-8161 

COMMUNICATIONS REPRESENTATIVE 

Robert W. McCarley 
Millsaps College 
Jackson, MS 39210 
(601) 354-5201 


NEWSLETTER EDITOR 
Fred Bell 
Taft College 
29 Emmons Park Drive 
P.O. Box 1437 
Taft, CA 93267 
(805) 763-4282 
PSS COORDINATOR 
VAX SYSTEMS SIG LIAISON 
Donald C. Fuhr 
Tuskegee Institute 
Tuskegee Institute, AL 36088 
(205) 727-8242 

ADMINSTRATIVE APPLICATIONS COORD. 

Dave Cothrun 
Taft College 
29 Emmons Pk Drive 
P.O. Box 1437 
Taft, CA 93268 
(805) 763-4282 

SESSION NOTE EDITOR 

Paula Barnes 
Guilford College 
5800 West Friendly Avenue 
Greensboro, NC 17410 
(919) 292-5511 
DEC COUNTERPART 
Gary Finerty 
Marlboro, MA 


O Graphics 
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GRAPHICS APPLICATIONS SIG 

CHAIRMAN 

William Kramer 

NAS Systems Engineering Branch 
NASA Ames Research Center 
Moffett Field, CA 94035 
(415) 694-5189 

SYMPOSIA COORDINATOR 

Bijoy Misra 

Smithsonian Institution 
60 Gordon St, MS39 
Cambridge, MA 02138 
(617) 495-7392 

COMMUNICATIONS REPRESENTATIVE 
NEWSLETTER EDITOR 
Michael Anton 
Schlumberger 
P.O. Box 591293 
Houston, TX 77259-1293 
(713) 928-4838 

ASSOCIATE NEWSLETTER EDITOR 

Charles D. Carter 
Huntington Alloys, Inc. 

Technology Dept 
P.O. Box 1958 
Huntington, WV 25720 
(304) 526-5721 

WORKSTATION WORKING GROUP COORD. 

Bob McCormick 

Video Communications, Inc. 

1325 Springfield Street 
Feeding Hills, MA 01030 
(413) 786-7955 

ENGINEERING GRAPHICS WORKING GROUP COORD 
Eric Rehm 
Gonzaga University 
SPOCAD 
E 502 Boone 
Spokane, WA 99258 
(509) 484-6814 


SESSION NOTE EDITOR 

Carol Schwob 
Florida Altantic University 
Academic Computing 
500 N.W. 20th Street 
Boca Raton, FL 33431 
(305) 393-2640 

LIBRARY COORDINATOR 

Mike McPherson 
Michigan University 
269 Engineering Bldg. 

East Lansing, MI 48824 
(517) 353-9769 

STANDARDS COORDINATOR 
Jim Flatten 
Ames Lab 
2581 Metals Dev. 

Ames, IA 50011 
(515) 294-7908 

VOLUNTEER COORDINATOR 

Dick McCurdy 
University of Florida 
Room 216, Larsen Hall 
Gainsville, FL 32611 
(904) 392-4915 
LIBRARY COMMITTEE 
James M. Turner 
Saber Technology 
San Jose, CA 
DEC COUNTERPART 
Rick Berzle 
Spit Brook, NH 

INFORMATION OFFICER 

Mike York 

Boeing Computer Services 
P.O. Box 24346 M/S 03-73 
Seattle, WA 98124 
(206) 342-1442 

HUMAN INTERFACE WORKING GROUP COORD. 
Dottie Elliott 
Northrop Services Inc. 

P.O. Box 12313 

Research Triangle PK, NC 27709 
(919) 541-1300 

DATA DISPLAY WORKING GROUP COORD. 

Joy Williams 
Eaton Corp. 

P.O. Box 766 
Southfield, MI 48037 



HARDWARE MICRO SIG 

CHAIRMAN 

VAX SIG LIAISON 
Thomas J. Provost 
MIT/LNS Bates Linac Facility 
Middletown, MA 

PRODUCT PLANNING COORDINATOR 

George Hamma 
Synergistic Technology 
Cupertino, CA 

SYMPOSIA COORDINATOR 
PRE-SYMPOSIUM SEMINAR COORDINATOR 

Mike Allen 

Lawrence Livermore Nat’l Lab. 

Livermore, CA 

COMMUNICATIONS COORDINATOR 

John G. Hayes 
Information Systems 
South Central Bell 
Birmingham, AL 
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NEWSLETTER EDITOR 

William K. Walker 
Monsanto Research Corp. 

Miamisburg, OH 
ASSISTANT EDITOR 

Carmen D. Wiseman 
Digital Review 
Boston, MA 

SESSION NOTE EDITOR 
DAARC SIG LIAISON 

Bill Tippie 

Kinetic Systems Corp. 

Lockport, IL 

STANDARDS COORDINATOR 

CAMAC WORKING GROUP COORDINATOR 

Peter Clout 

Los Alamos National Lab 
los Alamos, NM 
LUG COORDINATOR 
Gregg Giesler 
Los Alamos Science Lab 
Los Alamos, NM 
TOEM (CHIPS & BOARDS) 

Jack J. Peterson 
Horizon Data Systems 
Richmond, VA 

HHK (HARDWARE HINTS & KINKS) 

Wayne Kesling 
Monsanto Research Cor. 

Miamisburg. OH 
UNIBUS HARDWARE 
Ron Bogue 

LIV Aerospace & Defense Co. 

Dallas, TX 

PERFORMANCE MEASUREMENT COORD. 
William Wallace 
600 W. Washington Street 
Peoria, IL 

CSS COORDINATOR 
Pratap Gohel 
E.I. duPont 
Ingleside, TX 

NETWORKS SIG LIAISON 

Sandra Traylor 
Target Systems 
Yorba Linda, CA 
VAX SIG LIAISON 
Dave Schmidt 
5100 Centre Avenue 
Pittsburgh, PA 
UNISIG LIAISON 

Jim Livingston 
1 Results Way 
Cupertino, CA 
SITE SIG LIAISON 
Emily Kitchen 
A.H. Robins Co. 

Richmond, VA 
RT-11 SIG LIAISON 
Gary Sallee 

Sallee Software Consulting 
yorba Linda, CA 
RSX SIG LIAISON 
Hans Jung 
Associated Press 
New York, NY 
MEMBERS-AT-LARGE 
Mike Rembis 
American Dade 
Costa Mesa, CA 
Hans Dahlke 
Richland, WA 
Jim Cutler 
EDS Tower 
16533 Evergreen 
Southfield, MI 

DEC COUNTERPARTS TERMINALS 
Nina Abramson 
Maynard, MA 
TOEM (Chips & Boards) 

Art Bigler 
Marlboro, MA 


DIAGNOSTIC 

George D. Cooke 
Maynard, MA 
STORAGE 

Marilyn Fedele 
Maynard, MA 

MSD (Micro Systems Develp.) 
Roy Rodgers 
Maynard, MA 
PRINTER PRODUCTS 
Frank Orlando 
Maynard, MA 

DECUS EUROPE LIAISON 

Hans Zoller 



IAS SIG 

CHAIRMAN 

Mike Robitaille 
Grumman - CTEC, Inc. 

6862 Elm Street 
McLean, VA 22101 
(703) 556-7400 x 431 
NEWSLETTER EDITOR 
Frank R. Borger 
Radiation Therapy 
Michael Reese Medical Center 
Lake Shore Drive @ 31st St. 
Chicago, IL 60616 
(312) 791-2515 

WHIMS COORDINATOR 

Kathleen Anderson 
Eaton Information Management 
System Division 
Hampton, VA 
(804) 326-1941 
RSX LIAISON 

Ray French 

Boeing Computer Services 
Seattle, WA 
(206) 655-6228 
MEMBER-AT LARGE 
Doug Reno 
Abbot Laboratories 
North Chicago, IL 
(312) 937-7504 
CHAIRMAN EMERITUS 
Bob Curley 

Division of Medical Physics 
University of Pennsylvania 
Philadelphia, PA 
(215) 662-3083 

SYMPOSIA COORDINATOR 

Lynda L. Roenicke 
Special Systems Branch 
Naval Ocean Systems Center 
271 Cataline Blvd Code 742 
San Diego, CA 
(619) 225-7569 

LIBRARY COORDINATOR 

Bob Schuldt 
INCO Inc. 

McLean, VA 

MEMBER-AT-LARGE 

Kerry Wyckoff 
Salt Lake City, UT 
DEC COUNTERPART 

Nancyfaye Autenzio 
Stow, MA 
(617) 496-9606 



LANGUAGES AND TOOLS SIG 

CHAIRMAN 

Sam Whidden 

American Mathematical Society 
201 Charles St. 

P.O. Box 6248 
Providence, RI 02940 
(401) 272-9500 
VICE CHAIR 

SYMPOSIA COORDINATOR 

Earl Cory 
Eaton Corporation 
31717 Latienda Dr. 

Westlake Village, CA 91359 
(818) 706-5385 

COMMUNICATIONS REPRESENTATIVE 
STORE REPRESENTATIVE 

CHAIR, TECH. PROD. OF DOC. WORKING GROUP 

Howard Holcombe 
RCA 

Front & Cooper Sts. 

Camden, NJ 08055 
(609) 338-4946 
NEWSLETTER EDITOR 
A1 Folsom, Jr. 

Fischer & Porter Co. 

E. County Line Rd. 

Warminster, PA 18974 
(215) 674-7154 

SESSION NOTES EDITOR 

Mark Katz 

GTE Government Systems 
100 First Avenue 
Waltham, MA 02154 
(617) 466-3437 

AUSTRALIAN L&TINTERFACE 

Gordon Brimble 
Bldg. 180 Labs Area 
Defence Research Centre 
Box 2151 GPO 

Adelaide, S.A. Australia 5001 
(61)(8)259-6119 

INTERSIG COORDINATOR 

Dorothy Geiger 
Wollongong Logistics Group 
49 Showers Drive #451 
Mountain View, CA 94040 
(415) 948-1003 
EUROPEAN METHODS 
L&T INTERFACE 
Bemd Gliss 
Max-Planck-Institute 
Heisenbergstra Be 1 
7000 Stuttgart 80, W. Germany 
(711) 686-0251 
DMS & DTR LIAISON 
Keith Hare 
JCC 

P.O. Box 381 
128 West Broadway 
Granville, OH 43023 
(614) 587-0157 
DEC COUNTERPART 
Celeste LaRock 
110 Spit Brook Road 
ZK02-3/Q08 
Nashua, NH 03062 
PAST CHAIR 

PRODUCTIVITY TOOLS COORDINATOR 

Kathy Hornbach 
Digital Equipment Corporation 
110 Spit Brook Rd., ZK02-2/R55 
Nashua, NH 03062 
(603) 881-2505 

CHAIR TECO WORKING GROUP 

Mark J. Hyde 

Advanced Computing Services 
209 Ardsley Drive 
DeWitt, NY 13214 
(315) 446-7223 
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CHAIR, BASIC WORKING GROUP 
MEMBER, ANSI BASIC X3J2 STDS, COMM. 

Stephen C. Jackson 
SCJ Consulting, Inc. 

7260 University Avenue N.E. 

Suite 105 

Minneapolis, MN 55432 
(612) 571-8430 

CHAIR, CONFIG. MGMT. WORKING GROUP 

Mark Alan Kidwell 
Texas Instruments Inc. 

P.O. Box 869305 M/S 8435 
Plano, TX 75086 
(214) 575-3547 

DEC COUNTERPART PDP-11 SOFTWARE 

Joe Mulvey 

Digital Equipment Corp. .ZK01-3/J10 
110 Spit Brook Road 
Nashua, NH 03062-2642 
(603) 881-1218 

LISP/AI COORDINATOR 

Don Rosenthal 

Space Telescope Science Institute 
Homewood Campus 
Baltimore, MD 21218 
(301) 338-4844 

LIBRARY REPRESENTATIVE 

SIG TAPE LIBRARIAN 

PUBLIC DOMAN SOFTWARE W/G CHAIR 

Tony Scandora 

Argonne National Laboratory 
CMT 205 

Argonne, IL 60439 
(312) 972-7541 

CHAIR, C WORKING GROUP 

James Maves 
Eaton Corp, IMSD 
31717 Latienda Drive 
Box 5009 

Westlake Village, CA 91359 
(818) 706-5375 

STANDARDS COORDINATOR 
TOOLS INTEGRATION W/G CHAIR 

Jay Wiley 

Bechtel Power Corp 
12400 East Imperial Highway 
Norwalk, CA 90650 
(213) 807-4016 
ASS’T TO CHAIR 

JR Westmoreland 
Custom Software Products 
UTAH Power & Light 
1407 West North Temple 
Annex 6/208 
Salt Lake City, UT 84116 
(801) 535-4784 

RECORDING SECRETARY 

Melodee Westmoreland 
Custom Software Products 
1456 E. Hilda Drive 
Fruit Heights, UT 84037 
(801) 533-2350 

SESSION CHAIRS COORDINATOR 

Gary C. Lelvis 
IMSL 

2500 Park West Tower One 
2500 City West Blvd. 

Houston, TX 77042-3020 
(713) 782-6060 

CHAIR, FORTRAN WORKING GROUP 
Scott Krusemark 
8473 Daisywood Ave N.W. 

North Canton, OH 44720 
(261) 499-6251 

VOLUNTEERS COORDINATOR 
Louise Wholey 
Measurex Corp 
1 Results Way 
Cupertino, CA 95014 
(408) 255-1500 x 5571 
CHAIR, MACRO WORKING GROUP 
CHAIR, BLISS WORKING GROUP 
Gerald Lester 

Computerized Processes Unlim. 

2901 Houma Blvd. Suite 5 
Metairie, LA 70006 
(504) 889-2784 


HUMAN INTERFACE COORDINATOR 

CHAIR, COBOL GENERATOR WORKING GROUP 

CHAIR, TRAINING & ED SERV. WORKING GROUI 

Jim Wilson 
Pfizer 
QC Division 
P.O. Box 88 
Terre Haute, IN 47808 
(812) 299-2121 x 271 
VICE CHAIR 

Terry Medlin 
Survey Sampling, Inc. 

1 Post Road 
Fairfield, CT 06432 
(203) 255-4200 

CHAIR, DIBOL WORKING GROUP 

Bruce Mebust 
Vicom 

9713 Valley View Road 
Eden Prairie, MN 55344 
(612) 944-7135 

MASTERS COORDINATOR 

Dena Shelton 
Cullinet Software Inc. 

2860 Zanker Rd, Suite 206 
San Jose, CA 95134 
(408) 434-6636 

APL WORKING GROUP CHAIR 
Bob Van Keuren 
UserWare International, Inc. 

2235 Meyers Ave 
Escondido, CA 92025 
(619) 745-6006 

WISHLIST COORDINATOR 

Shava Nerad 
MIT 

77 Mass Avenue W91-219A 
Cambridge, MA 02139 
(617) 253-7438 

WORKING GROUPS COORD. 

ASST. SYMPOSIUM LOGISTICS COORD. 

Joseph Pollizzi, III 
Space Telescope Science Institute 
3700 San Martin Drive 
Homewood Campus 
Baltimore MD 21218 
(301) 338-4901 

CHAIR, MODULA II WORKING GROUP 

Jack Davis 

Phillips Home Interactive Systems 
111 North Shore Drive 
Knoxville TN 37919 
(615) 558-5206 

CHAIR, SCAN WORKING GROUP 
CHAIR, PL/1 WORKING GROUP 

David Ream 
Lexi-Comp 

26173 Tallwood Drive 
N. Almstead, OH 44070 
(216) 777-0095 
(216) 468-0744 

CHAIR, PASCAL WORKING GROUP 

E. Wayne Sewell 
E-Systems, Garland Div. 

Box 660023, MS 53730 
Dallas, TX 75266-0023 
(214) 272-0515 x3553 

CHAIR, PDP-11 LAYERED PROD. W/G 

William I. Tabor 
W.I. Tabor, Inc. 

11652 N.W. 30th St. 

Coral Springs, FL 33065 
(305) 755-7895 

CHAIR, SOFTWARE METRICS W/G 

Michael S. Terrazas 
LDS Church 

50 E. North Temple, 27th Floor 
Salt Lake City, UT 84150 
(801) 531-3246 

CHAIR, RPG WORKING GROUP 

Charles Williamson 
Hargray Telephone Co. 

P.O. Box 5519 

Hilton Head Is., SC 29938 

(803) 686-1204 


CHAIR COBOL WORKING GROUP 

Edward W. Woodward 
SAIC 

10210 Campus Point Drive 
M/S #24 

San Diego, CA 92121 
(619) 546-3758 
CLINIC DIRECTOR 
CHAIR, LARGE SYS. MAIN. W/G 
George Scott 
Computer Sciences Corp. 

304 West Route #38, P.O. Box N 
Moorestown, NJ 08057 
(609) 234-1100 

STEERING COMMITTEE MEMBERS 

Ted Bear 
Ramtek 

2211 Lawson Lane 
Santa Clara, CA 95950 
(408) 988-2211 
Ray Strackbein 
P.O. Box 7487 
Mission Hills, CA 91346 
(805) 254-8811 



LARGE SYSTEMS 

CHAIR 

Leslie Maltz 

Stevens Institute of Technology 
Computer Center 
Hoboken, NJ 07030 
(201) 420-5478 

BITNET: LM ALTZ@ SITVXB; 

ARPANET: SIT.MALTZ@CU20B.COLUMBIA.EDU 
SYMPOSIA COORDINATOR 
Robert C. McQueen 
Stevens Institute of Technology 
Computer Center 
Hoboken, NJ 07030 
(201) 420-5454 

BITNET: RMCQUEEN@ SITVXB; 

ARPANET: SIT.MCQUEEN@CU20B.COLUMBIA.EDU 

COMMUNICATIONS REPRESENTATIVE 
NEWSLETTER EDITOR 

Clyde Poole 

The University of Texas at Austin 
Department of Computer Science 
Taylor Hall 2.124 
Austin, TX 78712-1188 
(512) 471-9551 

ARPANET:ctp@ sally,utexas.edu 
MENU COORDINATOR 
Charles R.T.Bacon 
National Institutes of Health 
Building 12B Room 2N207 
Bethesda, MD 20205 
(303) 496-4823 

BITNET:CRB@NIHCUDEC 

HARDWARE COORDINATOR 

Clive Dawson 

Microelectronics & Computer Technology Corp. 

9430 Research Blvd. 

Echelon Bldg. #1, Suite 200 
Austin, TX 78759 
(512) 343-0860 

ARPANET/CSNET:CLIVE @ MCC. COM 
LANGUAGES COORDINATOR 
David Edwards 
SRI International 
MS PN 349 
333 Ravenswood Ave. 

Menlo Park, CA 94021 
(415) 859-6136 
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ASST SYMPOSIUM COORDINATOR 

Betsy Ramsey 

American Mathematical Society 
P.0. Box 6248 
Providence, RI 02940 
(410) 272-9500 x 295 
ARPANET: EWR@XX.LCS.MIT.EDU 
SYSTEM SOFTWARE COORDINATOR 
Carla Rissmeyer 
University of Texas at Austin 
Computation Center 
Austin, TX 78712 
(512) 471-3241 

ARPANET:CC.RISSMEYER@ A20.CC.UTEXAS.EDU 
SPECIAL PROJECTS COORDINATOR 
E.F. Berkley Shands 
Washington University 
Department of Computer Science 
P.O.Box 1045 
St. Louis, MO 63136 
(314) 889-6636 

UUCP: BERKLEY@WUCS. UUCP 
NETWORKS COORDINATOR 
Don Kassebaum 
Computation Center 
University of Texas at Austin 
Austin, TX 78712 
(512) 471-3241 

ARPANET: CC.KASSEBAUM@ A20. CC. UTEXAS. EDU 
SITE SIG LIAISON 

Gary C. Bremer 
Emerson Electric Co. 

Electronics and Space Division 
8100 W. Florissant 
St. Louis, MO 63136 
(314) 553-4448/4447 
SPECIAL PROJECTS 

INFORMATION CENTERS COORDINATOR 

Ralph M. Bradshaw 
Johnson & Johnson 
Research & Scientific Services 
Management Information Center 
Raritan, NJ 08869-1489 
(201) 685-3434 
DEC COUNTERPARTS 
Dave Braithwaite 
Marlboro, MA 
Rich Whitman 
Marlboro, MA 
Reed Powell 
Marlboro, MA 



MUMPS SIG 

CHAIRMAN 

Mark Berryman 
Plessey Peripheral Systems 
Irvine, CA 

SYMPOSIA COORDINATOR 

Chris Richardson 
Computer Sciences Corp. 
Ridgecrest, CA 

NEWSLETTER EDITOR 
Mark J. Hyde 

Advanced Computing Services 
DeWitt, NY 
VAX LIAISON 

Coyett A.J. Dese 

VA DM&S Verification & Dev. Ctr. 
San Francisco, CA 
DEC COUNTERPARTS 
Beatrice Walther 
Marlboro, MA 
Diane Brown 
Marlboro, MA 
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NETWORKS SIG 

CHAIRMAN 

Stuart Lewis 
Douglas Furn. Corp. 

(312) 458-1505 

COMMUNICATIONS COMMITTEE REP. 
Bob Gustafson 
Northeast Utilities 
(203) 665-5082 
NEWSLETTER EDITOR 
Vickie Hess 
2510 Limestone Lane 
Garland, TX 75040 
(214) 495-7353 
SEMINAR UNIT REP & 

VICE (BACKUP) SIG CHAIR 
Sandy Traylor 
Target Systems, Inc. 

(714) 921-0112 

SYMPOSIA COORDINATOR 

Bill Hancock 
(817) 261-2283 

STANDARDS COORDINATOR 

Jim Ebright 
Software Results Corp. 

(614) 267-2203 

ASSISTANT NEWSLETTER EDITOR 
Judi Mandl 
UConn Health Center 
(203) 674-3912 

SESSION NOTES EDITOR 
Mary Marvel-Nelson 
General Motors Research Lab. 

(313) 986-1382 
DEC COUNTERPART 

Monica Bradlee 
(617) 486-7341 



OFFICE AUTOMATION SIG 

CHAIR 

Katherine “Kit” Trimm 
Pivotal, Inc 
Tucson, AZ 
(602) 886-5563 
VICE CHAIRMAN 

Ralph Bradshaw 
Johnson and Johnson 
Raritan, NJ 
(201) 685-3434 

COMMUNICATIONS REPRESENTATIVE 

E. Catherine Ditamore 
ARA Services 
Philadelphia, PA 
(215) 238-3638 

SYMPOSIA COORDINATOR 

Mitch Brown 
GenRad, Ind. 

Waltham, MA 
(617) 369-4400 x3052 
NEW MEMBER COORDINATOR 
Tricia Cross 

American Mathematical Society 
P.O. Box 6248 
Providence, RI 02940 
(401) 272-9500 


BOF COORDINATOR 
Ray Kaplan 
PIVOTAL, Inc. 

Tucson, AZ 
(602) 886-5563 
NEWSLETTER EDITOR 
Therese LeBlanc 
T.M. LeBlanc & Assoc. 

Wheeling, IL 
(312) 459-1784 
LIBRARY 

Bob Hassinger 

Liberty Mutual Research Center 
Hopkington, MA 
(617) 435-9061 

OA TAPE COORDINATOR 
Mary Jane Boiling 
Foreign Mission Board 
3806 Monument Avenue 
Richmond, VA 23230 
(804) 353-0151 
SYMPOSIA ASSISTANT 
Sal Gianni 
Northeast Utilities 
Hartford, CT 
(203) 665-5652 
STORE COORDINATOR 
Mike J ackson 
Air Force Operational 
Test and Evaluation Center 
Kirtland AFB, NM 
(505) 846-5641 

PERSONAL COMPUTER SIG LIAISON 

Cheryl Johnson 
Grinnell College 
Grinnell, IA 
(515) 236-2570 

OA LUG COORDINATOR 

Tom Orlowski 

American Council on Education 
1 DuPont Circle (Suite 110) 
Washington, DC 
(202)939-9371 

OA SIG COORDINATOR 

Joe Whatley 
Neilson Media Research 
375 Patricia Avenue 
Dunedin, FL 33528 
(813)734-5473 



PERSONAL COMPUTER SIG 

CHAIR 

Barbara Maaskant 
UT Health Science Center—CR 
7703 Floyd Curl Drive 
San Antonio. TX 78284 
(512) 567-2200 

PRO WORKING GROUP CHAIRMAN 

Thomas R. Hintz 
Univ. of Florida 
IFAS Computer Network, 

Bldg, 120 

Gainesville, FL 32611 
(904) 392-5180 

DECMATE WORKING GROUP CHAIRMAN 
PRE-SYMPOSIUM SEMINAR COORD. 

Vince Perriello 
Crosfield CSI 
570 Taxter Rd. 

Elmsford, NY 10523 
(914) 592-3600 
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VICE, CHAIR RAINBOW W/G CHAIRMAN 

Lynn Jarrett 

Union Tribune Publishing Co. 

P.O. Box 191 
San Diego, CA 92108 
(619) 299-3131 xll30 

VAXMATE WORKING GROUP CHAIRMAN 

Frederick G. Howard 
Eastman Kodak Company 
901 Elmgrove Road, D345-LP 
Rochester, NY 14650 
(716) 253-2363 

VOLUNTEER COORDINATOR 

Pierre M. Hahn 
Suny HSC-T10-028-8101 
Stony Brook, NY 11794 
LIBRARIAN/Committee Rep. 

Ron S. Hafner 
Hafner and Associates 
P.O. Box 2924 
2499 Wellingham Dr. 

Livermore, CA 94550 
(415) 449-4178 

COMMUNICATIONS REPRESENTATIVE 
STORE REPRESENTATIVE 

Kenneth LeFebvre 
Sytek. Inc. 

19 Church St. 

P.O. Box 128 
Berea, OH 44017 
(216) 243-1613 
NEWSLETTER EDITOR 
Gary Rice 
McDonnell Douglas 
5555 Garden Grove Blvd. 

MS: K20 77/200 
Westminster, CA 92683 
(714) 952-6582 
DECmate W.G. CHAIR 

PRE-SYMPOSIA SEMINAR COORDINATOR 

Vince Perriello 

Crosfield Composition Systems 
570 Taxter Road 
Elmsford, NY 10523 
(914) 592-3600 

SYMPOSIA COORDINATOR 

Rick Eliopoulos 
5258 Vickie Drive 
San Diego, CA 92109 
(619) 225-7867 

SESSION NOTE EDITOR 

Dr. Tomas L. Warren 
Oklahoma State Univ. 

Dept of English 
Div. Tech. Writing Program 
Stillwater, OK 74078 
(405) 624-6138 

SYMPOSIA COORDINATOR 12/87 

Jim Wilson 

Ntl Tech Inst for the Deaf 
Rochester Inst, of Tech 
P.O. Box 9887 
Rochester, NY 14623 
(716) 475-6241 
MEMBERS-AT-LARGE 
Michael Bowers 
Univ. of California 
Animal Science Department 
Davis, CA 95616 
(916) 752-6136 
Theodore Needleman 
Hardcopy Magazine 
Seldin Publishing, Inc. 

1061 S. Melrose, Suite D 
Placentia, CA 92607 
(714) 356-6331 
DEC COUNTERPARTS 
PRO 

To Be Identified 
Digital Equipment Corp. 

ML021-2/U12 
146 Main Street 
Maynard, MA 01750 


PERSONAL COMPUTING SYSTEMS GRP. 

Anita Uhler 

Digital Equipment Corp. 

LJ02/13 
30 Porter Road 
Littleton, MA 

CAMPGROUND COORDINATOR 

Jim Hobbs 

Technical Support Group 
Adolf Coors Co. (BC380) 

Golden. CO 80401-1295 
(303) 277-2855 



RSTS SIG 

CHAIRMAN 

Charles Mustain 

Stark County School system 

Louisville, OH 

SYMPOSIA COORDINATOR 
Glenn Dollar 

Digital Computer Consultants Inc. 

21363 Lassen St, Suite 205 
Chatsworth, CA 91311 
(818) 341-9171 

ASST SYMPOSIA COORDINATOR 

Wef Fleischman 
Software Techniques 
Cypress, CA 

NEWSLETTER EDITOR 

Open 

LIBRARY REPRESENTATIVE 

Susan Abercrombie 
Ventrex Laboratories Inc. 

Portland, ME 

PRE SYMPOSIA SEMINAR COORDINATOR 

Scott Castleberry 
1750 North Collins 
Suite 108 

Richardson, TX 75080 
(214) 437-3477 

WISH LISTS COORDINATOR 

Neal E. Goldsmith 
Software Techniques, Inc. 

Cypress, CA 

VICE CHAIRMAN 

WISH LISTS & TAPE COPY COORDINATOR 

Lynnell Koehler 
Campus America 
POISE Prod. Ctr. 

201 North Nevada Avenue 
Roswell, NM 88201 
(505)625-5500 
EDUSIG LIAISON 

George Wyncott 

Purdue University Computer Center 
W. Lafayette, IN 

RSTS PRODUCT PLANNING COORDINATOR 

Errol E. Ethier 

Information Design and Management, Inc. 
23 Hunting Avenue 
(617) 842-4220 
Shrewsbury, MA 
DEC COUNTERPART 
Kathy Waldron 

Digital Equipment Corporation 
Continental Blvd. 

Merrimack, NH 03054 


MEMBERS-AT-LARGE 

Edward F. Beadel 
Manager 

Instructional Computing Center 

S.U.N.Y. College at Oswego 

Oswego, NY 13126 

(315) 341-3055 

Mark Hartman 

Jadtec Computer Group 

546 W. Katella Avenue 

Orange, CA 92667 

(714) 997-8928 

Jeff Killeen 

Information Design & Management 
Hopedale, MA 
Newton J. Munson 
Rochester Institute of Technology 
Rochester, NY 


I MU.fl i out 
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RSX SIG 

CHAIRMAN 

Dan Eisner 
Perkin-Elmer Corp. 

Garden Grove, CA 
SYMPOSIA COORDINATOR 
Rick Sharpe 
Toledo Edison 
Toledo, OH 

PRE SYMPOSIUM SEMINAR COORDINATOR 

Hans Jung 
Associated Press 
New York, NY 

COMMUNICATIONS REPRESENTATIVE 

Jay Allen Bennett 
Lear Siegler Rapistan 
Grand Rapids, MI 

NEWSLETTER EDITOR 

MULTI PROCESSORS WORKING GROUP COORDINATOR 

Bruce Mitchell 

Machine Intelligence & Industry Magin 
Byron, MIN 

STORE COORDINATOR 
Jim Hopp 

Carlton Financial Computation 
South Bend, IN 

SESSION NOTE EDITOR 
Burt Janz 

Northern Telecom Inc. 

Concord, NH 
LIBRARIAN 

Glenn Everhart 
Mt Holly, NJ 

CAMPGROUND COORDINATOR 

Jerry Ethington 
Prolifix Inc. 

Frankfort, KY 
DEC COUNTERPARTS 
Lin Olsen 
Nashua. NH 
Dick Day 
Nashua. NH 

WORKING GROUP COORDINATOR 

Sharon Johnson 
Epidemiology 
Minneapolis, MN 
WORKING GROUP CHAIR 
Evan Kudlajev 
Philadelphia Electric Co. 

Philadelphia, PA 

RSX GROUP CHAIR SOFTWARE CLINIC COORD. 

Roy S. Maull 
U.S. Air Force 
Offutt AFB, NE 
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SOFTWARE CLINIC COORDINATOR 

Bruce Zielinski 
RCS 

Moorestown, NJ 

VOLUNTEER COORDINATOR 

Gary Maxwell 

U.S. Geological Survey 

Menlo Park, CA 

SRD WORKING GROUP COORDINATOR 

Bob Turkelson 

Goddard Space Flight Center 
Greenbelt, MD 

ACCOUNTING & PERFORMANCE WORKING GROUP COORD. 

Denny Walthers 
American McGaw 
Irvine. CA 

MENU COORDINATOR 

Ed Cetron 

Center for Biomedical Design 
Salt Lake City, UT 
MEMBERS-AT-LARGE 
Jim McGlinchey 
Warren ton, PA 
Jim Neel and 
Hughes Research Labs. 

Malibu, CA 

Anthony E. Scandora, Jr. 

Argonne National Laboratory 
Argonne, IL 
Ralph Stamerjohn 
Creve Coeur, MO 



RT-11 SIG 

CHAIRMAN 

John T. Rasted 
JTR Associates 
58 Rasted Lane 
Meriden, CT 06450 
(203) 634-1632 

COM. COM VOTING REP. 

COBOL CONTACT 

Bill Leroy 

The Software House, Inc. 

P.O. Box 52661 
Atlanta, GA 30355-0661 
(404) 231-1484 

STANDARDS COORDINATOR 

Robert Roddy 
Naval Ship Research Ctr. 
Bethesda, MD 20084 
(301) 227-1724 
MACRO CONTACT 

Nick Bourgeois 
NAB Software Services Inc. 
P.O. Box 20009 
Albuquerque, NM 87154 
(505) 298-2346 
NEWSLETTER EDITOR 
TECO CONTACT 

PRODUCT PLANNING CONTACT 

John M. Crowell 
Multiware, Inc. 

2121-B Second St Suite 107 
Davis, CA 95616 
(916) 756-3291 

NETWORKING CONTACT 

Jim Crapuchettes 
Omnex Corp. 

2483 Old Middlefield Way 
Mountain View, CA 94043 
(415) 966-8400 


WISH LIST CONTACT 
UNIX/ULTRIX CONTACT 

Bradford Lubell 
L.A. Heart Lab, UCLA 
10833 Le Conte Avenue 
Los Angeles, CA 90024-1760 
(213) 206-6119 
TSX & C CONTACT 
Jack Peterson 
Horizon Data Systems 
P.O. Box 29028 
Richmond, VA 23229 
(804) 740-9244 
RUNOFF CONTACT 
John Davis 

Naval Ship Research Center 
Code 2950 

Bethesda, MD 20084 
(301) 227-1592 
LUG CONTACT 

Ned Rhodes 

Software Systems Group 
2001 North Kenilworth St 
Arlington, VA 22205 
(703) 534-2297 

PERSONAL COMPUTERS 

Dennis V. Jensen 
AMES Labs. ISU/USDOE 
310 Metallurgy 
Ames, Iowa 50011 
(515) 294-4823 

SYMPOSIA COORDINATOR 

Milton Campbell 
Talisman Systems 
Drawer CP-255 
Manhattan Beach, CA 90266 
(213) 318-2206 

TAPE COPY GENERATION 
TAPE COPY DISTRIBUTION 
RT DECUS LIBRARY CONTACT 

Tom Shinal 
Syntropic Technology 
P.O. Box 198 
Waterford, VA 22190 
(703) 882-3000 

PRE-SYMPOSIUM SEMINAR 
RT-11 SUITE MANAGER 

Bruce Sidlinger 
Sidlinger Computer Corp. 
4335 N.W. Loop 410, #209 
San Antonio, TX 78229 

(512) DIG-ITAL 
BASIC CONTACT 

Ralston Barnard 
Div 7523 
Sandia Labs 

Alburquerque, NM 87185 
(505) 844-5115 

PRO RT-11 & HARDWARE 

Bill Walker 

Monsanto Research Corp. 
P.O. Box 32, A-152 
Miamisburg, OH 45342 

(513) 865-3557 
FORTRAN CONTACT 

Robert Walraven 
Multiware, Inc. 

2121-B 2nd St Suite 107 
Davis, CA 95616 
(916) 756-3291 
OTHER LANGUAGES 
Gary Sallee 
19912 Femglen Drive 
Yorba Linda, CA 92686 
(714) 970-2864 



SITE SIG 

CHAIRMAN 

DMS SIG Liason 
Larry W. Hicks 
Relational Database services 
P.O. Box 644 
121 S. Main St. 

Kernersville, NC. 27285-0644 
(919) 996-4882 

SYMPOSIA COORDINATOR 

Sue Abercrombie 
48 Malilly Rd. 

Portland, ME 04103 
(207) 772-2837 

SESSION NOTE EDITOR 
LARGE SYSTEMS SIG LIAISON 

Gary Bremer 
Emerson Electric Co. 

8100 W. Florisant 
St. Louis, MO. 63136 
(314) 553-4448 
NEWSLETTER EDITOR 
NETWORKS SIG LIAISON 
OA SIG LIAISON 

Gregory N. Brooks 
Washington University 
Behavior Research Labs 
1420 Grattan St 
St. Louis, MO. 63104 
(314) 241-7600 ext. 257 
LIBRARY COORDINATOR 
RSTS SIG LIAISON 

Timothy Frazer 

Specialized Bicycle Components 
15130 Concord Circle #77 
Morgan Hill, CA. 95037 
(408) 779-6229 

HARDWARE COORDINATOR 

HMS SIG Liason 
Emily Kitchen 
A.H. Robins Co. 

1211 Sherwood Ave. RT-2 
Richmond, VA. 23220 
(804) 257-2925 

COMMUNICATIONS COMMITTEE REPRESENTATIVE 
AI SIG Liason 

Terry C. Shannon 
Digital Review 
160 State St. 

6th Floor 

Boston, MA. 02109 
(617) 367-7190 

PRE-SYMPOSIA SEMINAR COORDINATOR 

Phillip Ventura 
STAFF MANAGEMENT 
Adam Zavitski 
Simmonds Precision ICD 
3100 Highland Blvd. 

Raleigh, NC. 27625 
(919) 872-9500 
MEMBERS-AT-LARGE 
Ann Goergen 
Texas Instruments 
13510 N. Central 
M/S 437 

Dallas, TX. 75266 
(214) 995-4629 
HMS SIG Liason 
RT SIG Liason 

David Hunt 

Lawrence Livermore National Lab 

MS L-230 

P.O. Box 808 

Livermore CA. 94550 

(802) 656-3190 

Gary Siftar 

Digital Equipment Corporation 
Tulsa, OK 
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DEC COUNTERPARTS 

Joe Allen 
Stow MA. 

Lil Holloway 
Bedford MA. 
Susan Porada 
Marlboro, MA. 




UNISIG 

CHAIRMAN 

Kurt Reisler 
Hadron Incorporated 
9990 Lee Highway 
Fairfax, VA 22030 
(703) 359-6100 
decvax! seismo! hadron! klr 
SYMPOSIA COORDINATOR 
Stephen M. Lazarus 
Ford Aerospace, MS X-20 
3939 Fabian Way 
Paulo Alto, CA 94304 
(415) 852-4203 
ihnp4!fortune!wdll!sml 
SESSION NOTE EDITOR 
Sam Kimery 
716 Second Street NW 
Rochester, MN 55901 
(507)281-1505 

COMMUNICATIONS REPRESENTATIVE 
NEWSLETTER EDITOR 

James W. Livingston 
Measurex Corporation 
1 Results Way 
Cupertino, CA 95014 
(408) 255-1500 x 5556 
ihnp4!decwrl!jwl 

ADMINISTRATIVE DAEMON 

Dorothy Geiger 
The Wollongong Group 
49 Showers Drive, 451 
Mountain View, CA 94040 
(415) 948-1003 
ihnp4!decwrl!dgeiger 
TAPE LIBRARIAN 

Carl Lowenstein 

Marine Physical Laboratory 

Scripps Institute of Oc'graphy, P-004 

LaJolla, CA 92093 

(619) 294-2678 

(ihnp4l decvaxi akguai dcdwesti ucbvax) 
! sdcsvax! mplvax! cdl 

USENET LIAISON 

Joe Kelsey 

FlexComm Corporation 
711 Powell Avenue, SW 
Renton, WA 98055 
allegra! fluke! joe 

STANDARDS COORDINATOR 

Jeff Gilliam 

National Semiconductor 

2900 Seminconductor Drive, MS C2303 

Santa Clara, CA 95051 

(408)721-3801 

ihnp4!nsc! voder! jeff 

MINISTER WITHOUT PORTFOLIO 

Norman Wilson 
Bell Laboratories, 2C-529 
600 Mountain Avenue 
Murray Hill. NJ 07974 
(201) 582-2842 

(decvaxi ihnp4)! research! norman 
DEC COUNTERPART 
Roseann Maclean 
Merrimack, NH 
(603) 884-5702 
decvax .'mac lean 


VAX SYSTEMS SIG 

SYMPOSIUM COORD., ASSISTANT 

David Cossey 
Computer Center 
Union College 
Schenectady, NY 12308 

SESSION NOTES EDITOR 

Ken Johnson 

Meridien Technology Corp. 

P.O. Box 2006 
St. Louis, MO 63011 
NEWSLETTER EDITOR 

Lawrence J. Kilgallen 
Box 81, MIT Station 
Cambridge, MA 02139-0901 
LIBRARIAN 

Glen Everhart 
25 Sleigh Ride Road 
Glen Mills, PA 19342 
VAXcluster WORKING GROUP 
Thomas Linscomb 
Computation Center 
University of Texas 
Austin, TX 78712 

NETWORK WORKING GROUP 

Bill Hancock 

Dimension Data Systems, Inc. 

P.O. Box 13557 
Arlington, TX 76094-0557 
MicroVAX WORKING GROUP 
Ray Kaplan 
Pivotal, Inc. 

6892 East Dorado Court 
Tucson, AZ 85715-3264 
(602) 886-5563 

SYSTEM IMPROVEMENT REQUEST (CORE) 

Mark D. Oakley 
Battelle Memorial Institute 
Room 11-6-008 
505 King Avenue 
Columbus. OH 43201-2669 
MULTIPROCESSOR WORKING GROUP 
Eugene Pal 
U.S. Army 

CAORA (ATORCATC) 

Fort Leavenw’orth, KA 

PRE SYMPOSIUM SEMINAR COORD. HISTORIAN 

Jeff Jalbert 
JCC 

P.O. Box 381 
Granville, OH 43023 

PRE-SYMPOSIUM COORD. (ACTING) 

June Baker 

Computer Sciences Corp. 

6565 Arlington Blvd. 

Falls Church, VA 22046 

REALTIME/PROCESS CONTROL WORKING GP 

Larry Robertson 

Bear Computer Systems Inc. 

56512 Case Avenue 
North Hollywood, CA 

FIELD SERVICE WORKING GROUP 

Dave Slater 

Computer Sciences Corp. 

6565 Arlington Falls Church, VA 22046 
LARGE SYSTEMS INTEGRATION WORKING GP 
Leslie Maltz 

Stevens Institute of Tech. 

Computer Center 
Hoboken. NJ 07030 
VOLUNTEER COORDINATOR 
Elizabeth Bailey 
222 CEB 

Tennessee Valley Authority 
Muscle Shoals, AL 35661 


COMMERCIAL WORKING GROUP 

Bob Boyd 

GE Microelectronics Center 
P.O. Box 13409, MS7T3-01 
Research Triangle Park, NC 27709-3049 
SECURITY 

C. Douglas Brown 
Sandia National Labs 
Division 2644 
P.O. Box 5800 

Albuquerque, NM 87185-5800 
MIGRATION AND HOST DEVELOPMENT 
VAXintosh WORKING GROUP 

Jim Downward 

KMS Fusion Incorporated 

P.O. Box 156D 

Ann Arbor, MI 48106 

REAL TIME/PROCESS CONTROL WORKING GP 

Dennis Frayne 
McDonnell Douglas 
5301 Bolsa Avenue 
Huntington Beach, CA 92646 
INTERNALS WORKING GROUP 
Carl E. Friedberg 
Seaport Systems, Inc. 

65 William Street, 9th Floor 
New York, NY 10038-2605 
COMMUNICATIONS ASSISTANT 
David L. Wyse 

Professional Business Software 
3680 Wyse Road 
Dayton, OH 45414-2539 

CAMPGROUND COORDINATOR 

Kirk Kendrick 
Shell Oil Co. 

333 Highway G, MS D-2146 
Houston, TX 77082-8892 
PAST CHAIR 

Marge Knox 
Computation Center 
University of Texas 
Austin, TX 78712 
System Management 
Steve Tihor 
251 Mercer Street 
New York, NY 10012 
ADVISORS 

Joseph Angelico 

U.S. Coast Guard Detachment 

National Data Buoy Center 

NSTL Station, MS 39529-6000 

Art McClinton 

Mitre 

1820 Dolley Madison Blvd. 

McLean, VA 22102 
A1 Siegel 

Battelle Memorial Institute 
505 King Avenue 
Columbus, OH 43201-2693 
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Ask the WOMBAT WIZARD 
Submission Form 

To submit a problem to the WIZARD, please fill out the form below 
and send it to: 

WW Editor, Philip A. Naecker 
Consulting Software Engineer 
3011 North Mount Curve Avenue 
Altadena, CA 91001 
USA 


Name:_ DECUS Membership No. 

Affiliation:__ 

Address: 


Telephone Number:_ 

Statement of Problem: 


Please following the following guidelines when submitting support 
material: 

1. If you are trying to demonstrate a method or a concept, 
please simplify the procedures, records, and other information 
to the shortest form possible. 

2. Annotate your attachments. Simple comments or hand-written 
notes ("Everything worked until I added this statement.") go a 
long way toward identifying the problem. 

3. Keep an exact copy of what you send. And number the pages 
on both copies. But send everything that is related to your 
question, even remotely. 

4. If you would like a direct response or would like your 
materials returned, please don't forget to include a stamped, 
self-addressed envelope large enough to hold the materials you 
send. 



QU-1 




DATATRIEVE/4GL SIG 

Product Improvement Request Submission Form 


Submittor: DECUS Membership Number: 

Address: Firm: 


Phone: Product or Products: 


How to write a PIR 

A PIR should be directed at a specific product or group of 
products. Be sure to give the full name of the product(s) and 
version numbers if applicable. Describe the functionality you 
would like to see in as complete terms as possible. Don't assume 
that the PIR editors or software developers know how it is done 
in some other software product - state specifically how you want 
the software to function. Provide justification of your request 
and give an example of its use. If you can, suggest a possible 
implementation of your request. 


Abstract: (Please limit to one or two short sentences.) 


Description and Examples: (Use additional pages as necessary.) 


[Put my name and address on reverse side, 


thus: ] 


PIR Editor, Philip A. Naecker 
Consulting Software Engineer 
3011 North Mount Curve Avenue 
Altadena, CA 91001 
USA 


QU-3 



DTR/4GL SIG Spring 1987 PIR Ballot 


DECUS Membership Number: 


CPU Types (Check all that apply): 

VAXes_ PDP-11's_ DECsystems_ Other (Specify)_ 

Application Types at your site (Check all that apply): 

_ Business EDP/MIS _ Software Development 

_ Education Engineering/Scientific 

_ Office Automation _ Service Bureau 

_ Other (Specify)_ 


Number of years using computers:_ Number of years using 4GL's: 


Products Used (Check all that apply): 

_ DTR-11 _ VAX-DTR _ CDD _ TDMS DBMS (any) 

_ FMS _ RSI _ Oracle _ Ingress 2ZH Rc *b 

_ Others (Specify)_____ 


PIR Number Points 


PIR Number Points 


Be sure to return your ballot by July 1, 1987 

Return to: 

Philip A. Naecker 
3011 N. Mount Curve Ave. 
Altadena, CA 91001 
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H M S 


S I G 


HARDWARE SUBMISSION FORM — A SIG INFORMATION INTERCHANGE 
Message _ 



Contact 
Name _ 

Address 


Telephone 


Type of equipment 


SUBMIT ANY TYPE OF HARDWARE PROBLEMS AND/OR FIXES. 

SEND TO: 

William K. Walker Carmen D. Wiseman 

Monsanto Research Corp. OR Digital Review 

P.O. Box 32 A-152 == Prudential Tower, Suite 1390 

Miamisburg, OH 45342 800 Boylston Street 

Boston, MA 02199 


QU-7 




IAS WHIMS 


WHAT: (Describe your WHIM) (Please print or type 


WHY: (Describe the reason for the WHIM) 


HOW: (Make any suggestions for a possible implementation 


Name: 
Company: 

Address: 


Phone: 


Please mail to: 

Kathleen M. Anderson 
EATON Information Management 
Systems Division 
2017 Cunningham Drive 
Suite 208 

Hampton, Virginia 23666 
Phone: (804) 326-1941 


QU-9 








IAS SIG MEMBERSHIP SURVEY 


Name: 
Address: 


Telephone: 


Current Hardware: (Include number and type of processors, mass 

storage devices, communication devices, etc.) 


IAS Release: (Indicate release of IAS under which these systems 
are running) 


Software: (Indicate software running on these systems, i.e., 
DECNET, Decus C, etc.) 


Application: (Indicate the type of application running on the 
system.) 


Contacts: Would you be willing to be placed on a list of contacts? 
If so, what areas? 


Features: Do you have any features which you would like IAS to include? 


Any further comments? 


QU-ll 



IAS SIG MEMBERSHIP SURVEY 


fold 


Frank R. Borger 
Michael Reese Medical Center 
Dept of Radiation Therapy 
Lake Shore Drive at 31st Street 
Chicago II 60616 
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Languages & Tools SIG 
MASTERS APPLICATION 


Name:_Title 

Company:_ 

Address:_ 


_Phone: ( ) __ 

Network Address:_Date:__ 

The Languages & Tools SIG has established the designation “LANGUAGES AND TOOLS MASTER”, to be 
applied to selected, qualified people willing to share their expertise in various subjects with others. Masters are people 
who are knowledgeable enough in one or more languages or tools to be comfortable answering questions about them. 
The qualifications of an L&T Master are: expertise in a specific area, a willingness to have his/her name published 
as a Master, and a willingness to volunteer services in different ways. Each product may have several Masters, and 
there is an overall Masters Coordinator who is a member of the L&T Steering Committee. 

Masters are asked to serve other users (and, under some circumstances, DEC), as a resource on products 
within their competence. In addition to being listed in the L&T Masters Directory (published in the newsletter) 
as available for occasional telephone consultation, Masters may act as ‘Doctors’ at Symposium Clinics, present 
Symposium sessions on the products of interest to them, field test products, interact with DEC product managers 
when appropriate, or act as a reference for a product for Digital salespeople. Especially on mature products, the 
SIG is anxious for knowledgeable users to offer product tutorial sessions at Symposia, and Masters can be of great 

help here. At Symposia, Masters will wear an identifying button bearing the legend “Ask Me About ” and the 

name of the language or tool in which he/she specializes. 

If you’d like to serve as an L&T Master, please mark the products on which you are willing to answer questions 
with an (for Master). Please mark any other products running at your site with an “A” (for “also running”) 

to provide users with a broader picture of your facilities. (Although not an L&T product, Mumps is included here 
at the request of the Mumps SIG as a service to Mumps users). You may request removal of your name from the 
Masters Directory at any time, although you may continue to be listed for a month or two, because of publication 
lead times. 

I am qualified to act as an L&T Master for the following products: Mumps 

Test Manager 
Runoff & DSR 
TeX & IAT e X 
Cobol Generator 
Software Project Mgr 


Debug 
Pascal 
Fortran 
Document 
VAX Notes 


Bliss 

Basic 

Cobol 

Dibol 

Emacs 


CMS 

MMS 

LSE 

SCA 

PCA 


TPU 

EVE 

EDT 

TECO 

PL/I 


C 

Ada 1 

APL 

RPG 

Scan 


Briefly describe your experience with those you checked. 


How long have you held your present position?_ 

Are you able to attend at least one symposium each year?_ 

Users are encouraged to seek assistance with products by calling appropriate Masters listed in the Directory. 
As a Master, your name and telephone number will be published in the Masters Directory, and users will call on you 
for limited help from time to time. Please check, below, any additional activities you might do: 

| | Field-test new versions of your product at your work site. 

| | Provide feedback on the product when needed by its DEC product manager. 

| [ Act as a reference for the product at the request of Digital Sales or Marketing people. 

Mail to: Dena Shelton, L&T SIG Masters Coordinator, Cullinet Software, Inc., 2860 Zanker Road, 
Suite 206, San Jose, CA 95134. 


1 Ada is a trademark of the DoD 
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Languages & Tools SIG 
WISHLIST QUESTIONNAIRE 

Name:_Title_ 

Company:__ 

Address:__ 


_Phone: ( ) _ 

Network Address:_Date: _ 

The Languages & Tools SIG is principally concerned with the DEC and public domain software products listed 
below. If your request directly involves one of these products, please check which one (if you have more than one 
request, please use a separate form for each): 



Debug 


Bliss 

n 

CMS 


TPU 


C 



Pascal 


Basic 


MMS 


EVE 


Ada 1 



Fortran 


Cobol 


LSE 


EDT 


APL 



Document 


Dibol 


SCA 


TECO 


RPG 



VAX Notes 


Emacs 


PCA 


PL/I 


Scan 



Test Manager 
Runoff & DSR 
TfcX & UT e X 
Cobol Generator 
Software Project Mgr 


If your request or suggestion doesn’t relate to one of the products listed above, check which one of the following 
Language & Tools SIG topics it concerns: 



Newsletter 


Symposium Sessions 


Pre-Symposium Seminars 


Masters Program 


Working Group Activities 


Session Notes 

— 

Information Folder 

Other L&T SIG topic: 

— 

SIG Tape 

— 

DECUS Store Item 


Wish List Request —brief description: 


Complete description—please explain your request thoroughly; don’t assume we know details of other products or 
services; give examples.- 


Mail to: Shava Nerad, L&T Wishlist Coordinator, MIT, 77 Mass Ave. W91-219A, Cambridge, MA 
02139; (617)253-7438 


1 Ada is a trademark of the DoD 
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DHTHGRfim 


DATAGRAMS are short messages, comments, requests, or answers 
th8t are published in NETwords. Please fill in the sections below 
and send the DATAGRAM to: 

Vickie Hess 
NETWords Editor 
2510 Limestone Ln. 

Garland, Tx. 75040 


Title:_ 

Message: 


Your Name: _ 

Address: _ 

Telephone: _ 

If this is a reply to a previous DATAGRAM, what _ 

Signature:_Date:_ 


QU-17 




Place | 
Stamp; 
Here j 


Vickie Hess 
NETWords Editor 
2510 Limestone Ln. 
Garland, Tx. 75040 


Iol<3 Here 
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OFFICE AUTOMATION SIG 

SYSTEM IMPROVEMENT REQUEST SUBMISSION FORM 


Name _ 

Firm _ 

Telephone 


INSTRUCTIONS: System Improvement Requests (SIR) can be either hardware of 

software; please check the category addressed by this SIR. Under ABSTRACT, give a 
brief definition of the capability you would like. In the DESCRIPTION section, give a 
detailed description and examples of what you want. Be specific; don’t assume that we 
know how other products function. Justify the usefulness of the capability and give an 
example of its use. 



HARDWARE IMPROVEMENT 


SOFTWARE IMPROVEMENT 


DECmate_ ALL-IN-1 _ WPS_ 

PRO-Series_ CP/M (DECmate)_ P/OS _ 

Rainbow_ CP/M (Rainbow)_ MS-DOS 

Other_ Other 


ABSTRACT 



DESCRIPTION 





E. Catherine Ditamore 
ARA Services 
Corp MIS 
The ARA Tower 
1101 Market Street 
Philadelphia, Pa. 19107 
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DECmate Wish List Ballot 


Use this ballot to show which items on the DECmate Wish List are most important to 
you. Put the number of the most important item on the list in space 1, the next most 
in space 2, etc. 


1. 

10. 

19. 

28. 

37. 

2. 

11. 

20. 

29. 

38. 

3. 

12. 

21. 

30. 

39. 

4. 

13. 

22. 

31. 

40. 

5. 

14. 

23. 

32. 

41. 

6. 

15. 

24. 

33. 

42. 

7. 

16. 

25. 

34. 

43. 

8. 

17. 

26. 

35. 

44. 

9. 

18. 

27. 

36. 

45. 

add 

the following to 

the wish list: 




Comments: 


Name:_ 

Company: 
Address: 


Work Phone:_ 

Home Phone:_ 

Return Ballot to: 


Cheryl Johnson 

DECUS DECmate Working Group 

Grinnell College 

P.0. Box 805 

Grinnell, IA 50112-0810 
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Professional Wish List Ballot 


Use this ballot to show which items on the Professional Wish List are most important 
to you. Put the number of the most important item on the list in space 1, the next 
most in space 2, etc. 


1 . 

10. 

19. 

28. 

37. 

2. 

11. 

20. 

29. 

38. 

3. 

12. 

21. 

30. 

39. 

4. 

13. 

22. 

31. 

40. 

5. 

14. 

23. 

32. 

41. 

6. 

15. 

24. 

33. 

42. 

7. 

16. 

25. 

34. 

43. 

8. 

17. 

26. 

35. 

44. 

9. 

18. 

27. 

36. 

45. 

add the 

following to 

the wish list: 




Comments: 


Name:_ 

Company: 
Address: 


Work Phone:_ 

Home Phone:_ 

Return Ballot to: 


Thomas Hintz 

DECUS Professional Working Group 
University of Florida 
IFAS Computer Network 
1022 McCarty Hall 
Gainesville, FL 32611 
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Rainbow Wish List Ballot 


Use this ballot to show which items on the Rainbow Wish List are most important to you. Put 
the number of the most important item on the list in space 1, the next most in space 2, 
etc. 


1 . 

10. 

19. 

28. 

37 

2. 

11. 

20. 

29. 

38 

3. 

12. 

21. 

30. 

39 

4. 

13. 

22. 

31. 

40 

5. 

14. 

23. 

32. 

41 

6. 

15. 

24. 

33. 

42 

7. 

16. 

25. 

34. 

43 

8. 

17. 

26. 

35. 

44 

9. 

18. 

27. 

36. 

45 

add the 

following to 

the wish list: 




Comments: 


Name:_ 

Company: 
Address: 


Work Phone:_ 

Home Phone:_ 

Return Ballot to: 


Lynn Jarrett 

DECUS PC Sig Rainbow Working Group Chairman 

Union Tribune Publishing 

P.0. Box 191 

San Diego, CA 92108 
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PC POSTSCRIPT 

PC Postscripts are short requests, comments and responses to be published in the Postscript 
Section of the PC SIG Newsletter. Please respond to the following: 

_ Y/N This is a reply to a previous Postscript._Issue Mo. _ No. 


Title: 


Message:. 


Name: 

Address: 


Phone: (_) _-_ 

Signature: _ Date. 
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□ECUS PERSONAL COMPUTER SIG QUESTIONNAIRE 


General: 

I would like information on __ 

I would like to see an article 

in the newsletter on _ 

I would like to see a symposium 

session on _ 

I am willing to write an article(s) on: _ 

I am willing to be contacted by PC SIG members by telephone to give 

assistance/advice on: _ 

Phone number to call: Area Code (_) # _ Times _ 


I attend DECUS Symposiums : _always _Sometimes _never 

I expect to attend these symposiums _Fall 85 _Spring 86 _Fall 86 

I use/own: _Rainbow(s) _PRO(s) _DECmate(s) _Robin _Other_ 

I use the machine(s) checked above: _at work _at home _both 

If a work, total number of DEC PC's at your site: _____ 

I also use: _VAX _IBM or other mainframe _IBM/other PC 

Type of use: business _educational _government _other_ 

Primary Operating System: _MS-DOS _CP/M _both equally 

_P/OS _UNIX _other_ 

I belong to a local DEC PC Group: _yes _no 

There is a user group in my geographic area: _yes _no 

I would like information on starting a user group: _yes 

I use a modem: _often _reluctantly _never 

_for work _for pleasure _both 

Here is information on he DEC PC User Group I belong to or know of: 

Name of Group _ 

Name of Contact Person _ 

Address _ 


Telephone (_)_ 

Supports _Rainbow _PRO _DECmate _Robin _LUG _Gold Key 

Here is a DEC oriented bulletin board not on your list, or new information on a 
listed board: 


Name of Board _ 

Ful1 name of Sysop _ 

Address if known _ 

City and State _ 

Telephone Number _ 

Other Info: _ 

Supports _Rainbow _PRO _DECmate _Robin 


The subjects of greatest ineres to me are: 


_word processing 

_spreadsheets 

_database 

_graphics 

_communications 

_programming 

_software reviews 

technical articles 


_project management 

_specia1ized vertica1 

_(type)_ 

_Other:_ 

_Rainbow 

_PRO 

_DECmate 

Robin 


sof tware 
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_DEC Gossip and News _Other:_ 

If I had It to do over again, I: 

would buy another DEC Rainbow/PRO/DECmate (circle one 

_might buy another Rainbow/PRO/DECmate if it was a bargain (circle one_ 

_would not buy another Rainbow/PRO/DECmate (circle one) 

Will you continue to subscribe at the new price of $35/year? _yes _no 

Feel free to enclose another page(s) with comments! 

Do you feel that leaving the prices out of the newsletter: 

_is appropriate 

_is very annoying 

_makes the articles less useful 

Do you feel that Decus should revise its (anti Commercial ism policy? 

__yes 

no 


Name_ 

Company_ 

Address_ 

City/ST/ZIP_ 

Work Phone (_) 

Home Phone (_) 


Return to: 

Barbara Maaskant 
Computing Resources 
The University of Texas Health 
Science Center at San Antonio 
7703 Floyd Curl Drive 
San Antonio, Texas 78284 


fold here, flap under 


stamp 


Barbara Maaskant 
Computing Resources 
The University of Texas Health 
Science Center at San Antonio 
7703 Floyd Curl Drive 
San Antonio, Texas 78284 
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Information Resource Sign Up Sheet 
Personal Computing Special Interest Group - PC SIG 

Are you willing to be an information resource for other PC SIG members? Placing your name 
on the Contact List means you are willing to answer questions within the span of a brief 
telephone conversation. A Contact is not expected to be a consultant Please Register 
below. Your name and phone number (including restrictions) will be posted in the PC SIG 
Newsletter. 

First Name:_ Last Name:___ 

Address:__ 

City:_ State:_ ZIP:_ 

Phone: (_) _-_ 

Areas of Expertise:_ 


Suggestions for Additional Services the SIG can Provide: 




Barbara A. Maaskant 
UTHSCSA Computing Resources 
7703 Floyd Curl Drive 
San Antonio, Texas 78216 
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PERSONAL COMPUTING SPECIAL INTEREST GROUP 
VOLUNTEER FORM 


Name_ 

Company_ 

Address_ 

City_State-Zip Code. 

Telephone_ 

What special talents do you have?_ 


When do you attend symposia? 

D Always 0 Occasional Attendance 

□ East Coast Only □ Other (please specify) 

□ West Coast Only - 


Please check if you are interested In helping with any of the following activities: 


Symposia Related Activities: 

□ Session Chairs- D Articles for UpdateDaily 

□ Campground Volunteer_ □ Write letters of appreciation 

D Suite Volunteer- D Equipment Setup 

□ DECUS Store- 

□ Software Clinic- 

□ Panels- (indicate topics)- 

□ Technical Sessions- (indicate topics)- 

Ongoing SIG Activities: 

□ Working Groups_ (indicate which groups)_ 

0 Newsletter_ 

0 Public Domain Software Project_ 

0 Write Software for Special SIG Needs_ 


Other SIG Activities: (please specify) 


Do you wish to see the PCSIG undertake any activities which it is not currently doing? 
Please specify. 


Would you be willing to coordinate the activity you have listed above? □ Yes □ No 


Thank you 
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RSTS Newsletter Reader Survey 

In order to serve you better, the newsletter editor 
solicits the following information: 

I would to see a newsletter article on _ 

I am interested in a Symposium session on _ 

I am willing to write an article on _ 

I/my company have _ machines running RSTS version _ 

I attend the DECUS Symposia: _ Always _ Sometimes _ Never 

Do you/your company use DECmail-11? _ 

What other operating systems do you use MAIL with? _ 

Do you/your company use DECNET/E? _ 

What other operating systems do you use DECNET with? _ 

What other layered products do you use? _ 


Would you be willing to serve as an 'expert' on one of the 
above products? _ If so, which one(s)? _ 

If so, please give contact information: 

Name: _ 

Address: _ 


Phone: (_} _-_Ext. 


Other comments: 
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fold here 


Terence M. Kennedy 
St. Peter's College 
Dep't. of Computer Science 
2641 Kennedy Blvd. 

Jersey City, N.J. 07306 


fold here 





RT-11 WISH LIST SURVEY 


Name (optional) 
Address (optional) 


DECUS Number (optional) 


1.1 

3.1 

3.7u _ 

3.13a 

5.1b 

1.2 

3.2a 

3.7v 

3.13b 

5.2a 

1.3 

3.2b _ 

3.7w 

3.13c 

5.2b 

1.4 

3.2c 

3.7x _ 

3.13d 

6.1 

1.5 

3.2d 

3.7y 

3.14 

6.2a 

1.6 

3.2e 

3.7z _ 

3.15 

6.2b 

1.7a 

3.3a 

3.7aa 

3.16 

6.2c 

1.7b 

3.3b 

_ 3.7bb _ 

3.17a 

6.2d 

1.8 

3.3c 

3.7cc 

3.17b 

6.3 

1.9a 

3.3d 

3.7dd _ 

3.17c 

6.4a 

1.9b ' 

3.4a 

3.7ee 

3.17d 

6.4b 

1.9c 

3.4b 

3.8a 

3.17e 

6.4c 

1.9d 

_ 3.4c _ 

3.8b _ 

3.17f 

6.4d 

1.10 

3.5a 

3.8c 

3.18 

6.5 

1.11 

3.5b 

3.9a 

3.19a 

6.6a 

1.12 

3.6a 

3.9b 

3.19b 

6.6b 

1.13 

3.6b _ 

3.9c 

3.19c 

6.6c 

1.14 

3.6c 

3.9d 

4.1 

6.6d 

2.1 

3.6d _ 

3.9e 

4.2a 

6.7 

2.2 

3.6e 

3.9f 

4.2b 

6.8a 

2.3 

3.6f 

3.9g 

4.3 

6.8b 

2.4 

3.6g 

3.9h 

4.4a 

6.8c 

2.5 

3.7a 

3.9i 

4.4b 

1 6.8d 

2.6 

3.7b 

3 • 9 j 

4.5a 

6.8e 

2.7 

3.7c 

3.9k 

4.5b 

7 . 

2.8 

3.7d 

3.10a 

4.6 

8. 

2.9 

3.7e 

3.10b 

4.7a 

9.1 

2.10 

3.7f 

3.10c 

4.7b 

9.2a 

2.11 

3.7g 

3. lOd 

4.7c 

9.2b 

2.12 

3.7h 

3. lOe 

4.7d 

9.3a 

2.13 

3.7i 

3. lOf 

4.7e 

9.3b 

2.14 

3.7 j 

3. lOg 

4.7 f 

10.1 

2.15 

3.7k 

3. lOh 

4.7g 

10.2 

2.16 

3.71 _ 

3. lOi 

4.7h 

10.3 

2.17 

3.7m 

3.10 j 

4.7i 


2.18 

3.7n 

3.10k 

4 • 7 j 


2.19 

3.1o 

3.101 

4.7k 


2.20 

3.7p 

3.10m 

4.71 


2.21 

1 3.7q _ 

3. lOn 

4.7m 


2.22 

3.7r 

3.11a 

4.7n 


2.23 

3.7s 

3.11b 

4.7o 


2.24 

3.7t _ 

3.12 

5.1a 



Send Responses to: RT-11 Wish List Survey 
Multiware, Inc. 

2121-B Second St. Suite 107 
Davis, CA 95616 
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PAGESWAPPER - August 1987 - Volume 9 Number 1 
INPUT/OUTPUT Submission Form 

INPUT/OUTPUT Submission Form 

A SIG Information Interchange 
Please reprint in the next issue of the Pageswapper 

If this is a reply to a previous I/O, which number? _ 

Caption: _ 

Message: •_ 


Contact: 

Name _ 

Address 


Telephone _ 

Signature _ Date _ 

Mail this form to: Larry Kilgallen, PAGESWAPPER Editor 
Box 81, MIT Station, Cambridge, MA 02139-0901, USA 

To register for on-line submission, dial (in the United States): 
(617) 262-6830 and log in with the username PAGESWAPPER. 
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PAGESWAPPER - August 1987 - Volume 9 Number 1 

INPUT/OUTPUT Submission Form 


Tear out or photocopy reverse to submit an I/O item 


Larry Kilgallen, PAGESWAPPER Editor 
Box 81, MIT Station 
Cambridge, MA 02139-0901 
USA 
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PAGESWAPPER - August 1987 - Volume 9 Number 1 
System Improvement Request Submission Form 


System Improvement Request Submission Form 


Submittor: 
Address: 


How to write an SIR: 

Describe the capability you would like to see available on VAX 
systems. Be as specific as possible. Please don't assume we 
know how it's done on the XYZ system. Justify why the capability 
would be useful and give an example of its use. If you wish, 
suggest a possible implementation of your request. 

Abstract (Please limit to four lines): 


Description and examples (use additional pages if required) 


Page 1 of 

Firm: 

Phone: 
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PAGESWAPPER - August 1987 - Volume 9 Number 1 
System Improvement Request Submission Form 


Tear out or photocopy reverse to submit an SIR 


Mark D. Oakley 

Battelle Columbus Division 

Room 11-6-008 

505 King Avenue 

Columbus, Ohio 43201-2369 

USA 
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PAGESWAPPER - August 1987 - Volume 9 Number 1 
VAX Systems SIG Fall 1987 SIR Ballot 


VAX Systems SIG Fall 1987 SIR Ballot 


DECUS membership number _ (six digits) 

Our site uses the following VAX cpus (check all that apply) 

8700/8800 8600/8650 8500/8550 8300/8200 

11/780,11/782,11/785 11/750 11/730,11/725 

MicroVAX I,II _ MicroVAX 2000, VAXstation 2000 _ 

We use VAXes in the following applications(Check all that apply) 

Business EDP _ Software Development _ 

Education _ Computer Science Research _ 

Data Acquisition/Control_ CAD/CAM _ 

Service Bureau _ Hardware Development _ 

Scientific/Engineering _ Office Automation _ 

Telecommunications Other 


I support the following as the most important System Improvement 
Requests. (List from zero to fifteen SIR'S): 


I oppose the following SIR'S as detrimental. (List from zero to 
five SIR's): 


Mail to: 

Mark D. Oakley 

Battelle Columbus Division 

Room 11-6008 

505 King Avenue 

Columbus, OH 43201-2693 

USA 

To be counted, your ballot must be received by October 30. 
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PAGESWAPPER - August 1987 - Volume 9 Number 1 
VAX Systems SIG Fall 1987 SIR Ballot 


Tear out 'or photocopy reverse to vote on SIRS 

i 


Mark D. Oakley 

Battelle Columbus Division 

Room 11-6008 

505 King Avenue 

Columbus, Ohio 43201-2693 

USA 
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